- From: Robert Burns <rob@robburns.com>
- Date: Thu, 2 Aug 2007 02:51:40 -0500
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: HTML WG <public-html@w3.org>
On Aug 2, 2007, at 2:21 AM, Henri Sivonen wrote: > > On Aug 2, 2007, at 08:33, Robert Burns wrote: > >> On Aug 2, 2007, at 12:00 AM, Henri Sivonen wrote: >> >>> On Aug 1, 2007, at 18:54, Robert Burns wrote: >>> >>>> On Aug 1, 2007, at 10:34 AM, Henri Sivonen wrote: >>>>> I said that it is not of type ID as far as the XML Processor >>>>> (that is, the XML parser as defined by the XML 1.0 spec) is >>>>> concerned when there is no DTD declaring the attribute id to be >>>>> of type ID. Between the XML parser and later stages of >>>>> processing, you do want to assign IDness to id. I propose >>>>> acknowledging this explicitly in the spec and calling the >>>>> processing stage an "XHTML id Processor". This is analogous to >>>>> how xml:id gains its IDness after the XML Processor in the >>>>> DTDless case. >>>>> >>>>> (What I said above holds regardless of what lexical space is >>>>> allowed for the id attribute.) >>>> >>>> I think you're raising a completely different issue from what >>>> I'm trying to address. >>> >>> I said why id isn't subject to the constraints XML 1.0 places on >>> IDs *even if* it gains IDness between the XML parser and further >>> processing. This is pertinent to whether "XML compatibility" is a >>> real problem. >> >> I really don't understand what you're saying. > > I'm saying that an XML processor as defined by XML 1.0 does what it > is defined to do. It reports data to the application. The data > reported to the application says that the attribute id is of type > CDATA. XHTML5 doesn't change that. > > However, the application may put in a filter that changes things so > that to further parts of the application the type of id is reported > as ID. This is what an xml:id Processor does for the xml:id > attribute. This is also implementable. (I have implemented an > "XHTML id Processor" for SAX. It works.) > > Changing the type of the attribute id to ID *after* the XML > processor stage is desirable in order to be able to define # > selectors, the XPath id() function, document.getElementById() and > the HTML attributes that have IDREF-like semantics in terms of IDness. I think you're reading these recommendations in a way too compartmentalized fashion. An xml:id processing application is still and xml processing application. It doesn't start out as an xml processing application then die and become reborn as an xml:id processing application. It starts as xml and become xml and xml:id. The norms build upon the previous norms: xml -> xml namespace -> xml:id -> HTML5. We can make our @id attribute a XSD:string data type (or whatever). But if we make it data type ID and it doesn't conform to the XML requirements for ID then HTML5 is a non-conforming application of XML. Whether this has any practical consequences is another story. I don't know. But it certainly breaks the norms of XML. > >> However, on Aug 1, 2007, at 1:01 PM, Thomas Broyer wrote: >> >>> Yes. @id is NOT of type ID. >> >> Which says to me that @id will never gain IDness. > > It is a statement of fact when it is scoped to what happens *in the > XML processor*. This WG mustn't change the definition of what an > XML processor does. However, this WG can define a processing stage > that makes id gain IDness after the XML processor if this WG so > chooses. The xml:id spec is precedent. Again, whatever processing state this workgroup defines it's still a processing state occuring within an XML processor when the @id value achieves IDness. > >> If it did gain IDness at any time then I think we have XML 1.0 >> compatibility problems. > > Does the XSD spec create XML 1.0 compatibility problems by defining > the PSVI, in your opinion? (I'm not suggesting that the PSVI is > good or nice. I'm merely suggesting that it is layered on top of > XML 1.0 and is not "incompatible" with XML 1.0.) I'm not familiar with that. > > Does the xml:id spec create XML 1.0 compatibility problems, in your > opinion? No, I don't think so. I don't see anything in the xml:id spec that doesn't conform to the requirements of XML for ID. >> Since I'm not understanding what you're saying, perhaps you could >> draw on the XML 1.- document to show me how something that happens >> between the XML parser and further processing negates these norms. > > The XML 1.0 spec doesn't define further processing it is entirely > up to the application. That's the crux of the matter why XHTML5 > doesn't need to inherit arbitrary restrictions from XML 1.0 when > those restrictions don't concern the XML processor. If XHTML5 intends to be an XML application (that is processed by XML processors) then it does need to conform to the XML 1.0 norms. It needs to in the sense that if it doesn't then XHTML5 is a non- conforming XML application (with whatever consequences that brings, if any). We can also change the code point assignments of Unicode in a later processing stage, but still claim to be a Unicode application. We will then be a non-conforming Unicode application (with some pretty serious consequences; i.e., our glyphs will not match the characters as expected by authors). > I reiterate my drawing on the xml:id spec instead: > "The xml:id processor performs ID type assignment on all xml:id > attributes, even those that do not satisfy the constraints." > http://www.w3.org/TR/xml-id/#processing From the part you cite: "An xml:id error occurs for any xml:id attribute that does not satisfy the constraints" and later regarding errors: "A violation of the constraints in this specification results in an xml:id error. Such errors are not fatal, but should be reported by the xml:id processor. In the interest of interoperability, it is strongly recommended that xml:id errors not be silently ignored." > No doom or gloom occurs when ID type assignment is done on an > attribute whose value isn't an NCName. Perhaps not, but that recommendation doesn't go out of its way to encourage authors to produce non-NCName IDs. > As for precedent for changing the lexical space (and the value > space) of IDs, I point to XSD that makes the lexical space of > xsd:ID different from XML 1.0 DTD ID (albeit in the opposite > direction than XHTML5). Do you mean stricter rather than looser? Then that's not a precedent. Of course an XML conforming application can make anything stricter without violating the XML 1.0 norms. It's making it looser that violates the XML recommendation. The conversation is getting way too academic here. To try to bring it back down to Earth, I don't really think we'll be doing authors a favor by giving them a few more characters to use in their ID values. These are opaque values anyway, as the draft already says. Authors already have tens of thousands of characters available (nearly 100,000 if we permit XML 1.1). Do they really need a few more? Take care, Rob
Received on Thursday, 2 August 2007 07:51:46 UTC