Re: 3.6. The root element

On Tue, 31 Jul 2007 11:34:10 +0200, Robert Burns <rob@robburns.com> wrote:
>> It seems you're misunderstanding what this is about as well. The draft  
>> points out that for _HTML documents_ (solely text/html) the HTML  
>> element may have an attribute xmlns specified that has the literal  
>> value http://www.w3.org/1999/xhtml. The note then goes on to point out  
>> that this xmlns attribute, when specified, is different from the  
>> identically named attribute in the XML serialization.
>
> It may very well be that I'm misunderstanding the current draft.  
> However, you're missing the point of my email message. It is entirely  
> unhelpful to simply point out that a reviewer is misunderstanding the  
> draft.

I'm not sure why it's entirely unhelpful. It might give the reviewer a  
chance to produce wording that would make him understand the draft better,  
for instance. Also, technical specifications are hard to read. They  
require you to carefully study and read all references made in the draft,  
specifications have to be read several times to ensure you understand all  
the details, et cetera. They are very different from the latest edition of  
Harry Potter.


> [...] As it stands now, the entire section (except the first sentence)  
> reads mostly like an overly pedantic discussion about the @xmlns  
> attribute. It fails to provide enough information for either authors or  
> UA developers to know what they're supposed to do with this attribute  
> (it also fails to explain this in a way that acknowledges the two  
> possible serializations).

Representing an implementor, that sentence is completely clear. I happen  
to know it was also clear to Henri, who implements an HTML5 validator. As  
for authors, I suppose it is unclear to those who are not familiar with  
the HTML-DOM mapping and the technicalities of XML namespaces.


> For example, calling it a talisman in the first note forgets that we  
> have two serializations. If the point is merely to allow authors to  
> include the namespace for XML serialization compatibility, then why not  
> say that.

It doesn't help much with XML serialization compatibility as it is a  
different attribute (as the note points out). If you have to use the same  
source code and label it as both XML and HTML it might help a bit though,  
I suppose.


> It might also be worth mentioning that other attributes in the xmlns  
> namespace may be added to text/html document, but they too will be  
> ignored (if we're trying to create compatibility between the two  
> serializations).

I'm not sure how that would make the serializations compatible.


>> Personally I'm not really sure how it can be made more clear.
>
> You shouldn't feel obligated to reply to every email. If you don't have  
> something constructive to contribute, don't worry about it.

I thought my e-mail was constructive. Why wasn't it?



>> Actually, what was discussed at the top of this e-mail (and what I was  
>> referring to) is an authoring detail.
>
> It may be only an authoring detail. However, it is not written in a  
> clear manner that an author would understand when and where to use this  
> attribute (and when not to use this attribute) and what effect this  
> attribute would have when setting it.

Euh... "Though it has absolutely _no effect_ and no meaning, the html  
element, in HTML documents, may have an xmlns attribute specified, ..."


>> The draft does define what constitues a valid time string for instance  
>> in as much detail as how the UA has to parse them as it uses the same  
>> algorithm to do so. I suppose tutorials or maybe an introductory  
>> section in the specification can make this easier to comprehend.
>
> As I said, independent of other non-normative documents, our  
> recommendation should indicate to authors precisely how they should  
> write a real number or ratio or boolean without needing to read the  
> parsing algorithm.

Why is that a requirement?


> That's there for boolean perhaps, but in many cases, the current draft  
> does not provide these author-centric normative explanations.

Could you please point those out?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 31 July 2007 09:55:38 UTC