Re: 3.6. The root element

On Tue, 31 Jul 2007 12:20:35 +0200, Robert Burns <rob@robburns.com> wrote:
> [...] The Harry Potter comparison is just another case in point.

After I e-mailed the draft I wondered if people might took it as  
insult[1], it was not meant as such.


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

I haven't helped drafting these paragraphs. I'm not sure why the  
paragraphs are unhelpful either. They explain an importance difference  
between the meaningless xmlns attribute on <html> in HTML documents and  
the xmlns attribute as defined by the Namespaces in XML 1.0 specification.


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

The draft states: "It is allowed merely to make migration to and from  
XHTML mildly easier." Basically the same reason void elements can have a  
trailing slash at the end of their tag declaration.



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

I'm asking why it's a requirement that the definitions already given in  
the draft should not require reading a parsing algorithm.


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

unsigned integer: "A string is a valid non-negative integer if it consists  
of one of more characters in the range U+0030 DIGIT ZERO (0) to U+0039  
DIGIT NINE (9)."

signed integer: "A string is a valid integer if it consists of one of more  
characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9),  
optionally prefixed with a U+002D HYPHEN-MINUS ("-") character."

real number: "A string is a valid floating point number if it consists of  
one of more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT  
NINE (9), optionally with a single U+002E FULL STOP (".") character  
somewhere (either before these numbers, in between two numbers, or after  
the numbers), all optionally prefixed with a U+002D HYPHEN-MINUS ("-")  
character."

for <time>: "If the datetime attribute is not present, then the date or  
time must be specified in the content of the element, such that parsing  
the element's textContent according to the rules for parsing date or time  
strings in content successfully extracts a date or time."

For <progress> and <meter> they are indeed a bit vague.


[1]<http://krijnhoetmer.nl/irc-logs/whatwg/20070731#l-147>


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

Received on Tuesday, 31 July 2007 10:51:31 UTC