Re: ID Characters (was: Re: 3.4. Global attributes)

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