Re: 3.6. The root element

On Jul 31, 2007, at 4:55 AM, Anne van Kesteren wrote:

>
> 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.

OK I agree, it might help. However, by jumping in to insult reviewers  
while also providing some low-grade-ore feedback, it makes the task  
for reviewers much more difficult and unnecessarily uncomfortable.  
The Harry Potter comparison is just another case in point.

>> [...] 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.

Well speaking as an implementor who is also familiar with HTML-DOM  
mapping and the technicalities of XML namespaces, I can tell you the  
draft is not clear in that subsection. The difference between you and  
Henri on one hand and me on the other hand, is  that I haven't been  
intimately involved with drafting this spec. My guess is that you  
understand what those horribly drafted paragraphs say, because you  
already know what they're supposed to say. Though I imagine if you  
took a step back and tried to put yourself in the shoes of a first- 
time reader of the draft you would see just how unhelpful those  
paragraphs are.

>
>> 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.

So why are we including this attribute at all in the recommendation:  
in the authoring conformance criteria no less?

>> 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.

I guess I just meant that an XML serialization with these attributes  
would not get needlessly flagged by a text/html conformance checker  
(the foreign namespaced elements, attributes and other QNames might  
get flagged by the conformance checker but no the namespace  
declaration attributes. Again, I'm just trying to understand what the  
rationale is for including this attribute in the first place. If  
there is none than I guess that's leading to my confusion.

>>> 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?

Mostly I think your emails provide only a bare minimum of information  
and read more like defensive posturing trying to defend the draft in  
it's current state. I don't think the defensiveness is necessary.  
None of the reviewers are trying to insult the draft or its drafters.  
They are merely trying to provide constructive criticisms of the draft.

>>> 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, ..."

This merely begs the question of why this attribute is in the  
recommendation. You could replace "xmlns" with "whatchamacallit" and  
that sentence would have the same clarity (or lack thereof). Why does  
the recommendation include this attribute that has no no effect and  
no meaning and not the infinity of other attributes that also have no  
effect and no meaning?

>>> 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?

Because we're writing a recommendation that includes norms for  
authors and UAs and therefore authors are among are audience. Are you  
asking why it is a requirement for a document to address its  
audience? I really do no understand what you're asking here.

>> 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?

I thought I did. The unsigned integer, the signed integer, real  
number, ratio METER, PROGRESS, TIME all have lengthy algorithms that  
imply author conformance criteria without explicitly delineating the  
author conformance criteria. There may be other places, but those are  
the ones I've studied the most.

Take care,
Rob

Received on Tuesday, 31 July 2007 10:21:02 UTC