- From: Robert Burns <rob@robburns.com>
- Date: Thu, 2 Aug 2007 00:33:43 -0500
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: HTML WG <public-html@w3.org>
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. However, on Aug 1, 2007, at 1:01 PM, Thomas Broyer wrote: > > 2007/8/1, Robert Burns: >> >> On Aug 1, 2007, at 10:57 AM, Thomas Broyer wrote: >>> >>> I think it's about documents with multiple namespaces, where >>> XHTML5 is >>> an "embedded language" (e.g. an Atom feed). In this case, you'd like >>> to be able to assemble XHTML fragments from different sources and >>> don't have their @id's conflict. >>> I think "subtree" here means "subtree rooted at the 'root element'", >>> not "subtree rooted at the element bearing the id attribute". >>> ...just my own understanding, because I couldn't think of any other >>> meaning for this sentence. >> >> Given that and what you say in the next two blocks, are you then >> saying that we make no assumptions that an @id is of type ID? > > Yes. @id is NOT of type ID. Which says to me that @id will never gain IDness. If it did gain IDness at any time then I think we have XML 1.0 compatibility problems. Unless, you're saying at some point — "between the XML parser and further processing" — the document will cease to be an XML 1.0 document, then we have a compatibility problem. As I said before a value of type ID in an XML document: "must match the Name production; … must not appear more than once in an XML document as a value of this type;… and must uniquely identify the elements which bear them [throughout the XML 1.0 document]"[1]. 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. Take care, Rob [1]: <http://www.w3.org/TR/xml/#one-id-per-el)>
Received on Thursday, 2 August 2007 05:34:10 UTC