[whatwg] id and xml:id

[Henri Sivonen]

On Apr 4, 2006, at 19:35, fantasai wrote:

> Henri Sivonen wrote:
>>
>> I have now assessed the damage. It is not as bad as it looked  
>> like. :-)
>> Despite a flood of error messages, there were only three causes:
>> 1) Can't have wild card attributes on wild card elements in the  
>> wild  card content models of the script and style elements. (Not a  
>> big  deal. It is reasonable to restrict them to known style and  
>> script  languages.)
>
> That seems odd. You should be able to say "the content model of  
> this element
> is anything".
> http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-2.html#relax- 
> CHP-12-SECT-2.1

 From the spec:
"Thus, a RELAX NG schema that is compatible with this feature implies  
a mapping from element/attribute name pairs onto an ID-type, and  
hence a mapping from attributes in the instance onto ID-types."
( http://relaxng.org/compatibility-20011203.html )

"Any attribute" with ID-type null on "any element" competes with  
attribute id with ID-type ID on element foo. That's why the  
attributes with non-null ID-type would paired with known elements  
need to be subtracted from the "any" set.

Anyway to get better on topic for this list:

I think that a conformance checker / schema should forbid element  
children of <style> and <script> when the style sheet language or  
script language is known to be text that is passed to a non-XML  
parser for further processing. I'd worry about designing schemas that  
allow element children there only when someone actually develops an  
XML-based scripting or style language that is would otherwise be  
suitable for embedding in XHTML <style> or <script>. I don't see why  
a conformance checker or a schema should be open-ended and have an  
"anything goes" hole here--especially if the schemas are available  
for modification by prospective developers of such script or style  
languages.

Actually, it would be cool to have custom datatypes for JavaScript,  
JavaScript with E4X and CSS and throw the contents of <script> and  
<style> elements at a JavaScript or CSS parser. (I have not assessed  
the effort would be reasonable, though.)

>> 2) Jing complains about the IDREFness altering co-occurrence   
>> constraint between valuetype and value on the param element.
> >
>> 3) It appears that in RELAX NG an attribute can't be allowed to  
>> take  the empty string if the attribute has the IDREFS nature.  
>> This is a  problem with the form attribute.
>> See: http://groups.yahoo.com/group/rng-users/message/422
>
> Does moving the choice up higher help any?

According to the spec it should not help. I also tested moving the  
choice up in the latter case and, indeed, it did not help.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/