- From: Robert Burns <rob@robburns.com>
- Date: Wed, 1 Aug 2007 15:44:26 -0500
- To: Thomas Broyer <t.broyer@gmail.com>
- Cc: public-html@w3.org
Hi Thomas, 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. > >> This may be similar to me getting my head around the no versioning >> idea, >> but I sense you're saying HTML5 has some kind of weak typing. Is that >> correct? That would explain why there's little mention of data types. >> So if the HTML5 @id attribute is not of type ID but rather simply a >> string, we can deploy whatever uniqueness rules we want (even in >> XML). > > As far as "content attributes" are concerned, they're just "strings" > (DOM's getAttribute and getAttributeNS return DOMString-typed values). > "Datatyping" is only done when extracting typed values for rendering > or reflected attributes on the DOM interfaces or extracting semantics. > It is that way because of HTML's error recovery (errors are never > fatal): attributes might have invalid values but those errors are > recovered when "casting" the value (to e.g. a number or datetime). Well I understand that in terms of text/html processing. However,are we extending that to a notional sense of weak typing throughout the draft: a weak-typing that would extend to XML processing that doesn't have the same error recovery as HTML? There's certainly benefits in that approach, however I hadn't gotten a clear statement from the draft to that effect. Also in terms of authoring, there are some inclinations toward stronger typing in the sense that TIME@datetime takes a specific value (a string in a specific format) and anything else is an authoring error. So in parallel, would we say that @id takes a value of a specific data type like ID (or invent a new data type)? Or do we want to avoid burdening/helping authors with these sorts of strong attribute value types? Really these are separate questions. We can specify strict data types for each attribute and still not specify @id be anything like ID. I think it would be nice to make use of another recommendation such as XSD data types to specify our data types (even if we just use a small subset of what's available there). That offers some nice fine-grained data types with rigorous definitions and lifts the burden off of our shoulders. >>> Given that valid HTML4 and XHTML 1.0 documents would still be valid >>> (X)HTML5 documents, I don't see the problem. >> >> Well my concern would be that an HTML4 UA might have taken this >> portion of the HTML4 recommendation seriously and the compatibility >> would be broken (if testing has already indicated that's not the >> case, then I'm satisfied on that). > > If such an UA exists, it cannot work on the web today, because > published content is broken. > > [Various tests ...] > > > Not tested on other browsers. > Safari look right too. >> Will we not have an XML schema of any kind (DTD, XSD or otherwise)? > > If we finally do, it'll have to cope with the rules defined in the > prose (not the opposite). That goes without saying. However, I was probably more asking the question to get at whether we'll have any concept of data typing in our attribute values (especially @id) and what those might be. >> Should we include something in this subsection explaining that an >> @id is >> not of type ID? > > Maybe. We should, if that's the case. Too many readers of the recommendation will be likely to jump to that conclusion (as I did). Take care, Rob
Received on Wednesday, 1 August 2007 20:44:43 UTC