Re: 3.6. The root element

On Jul 30, 2007, at 7:53 AM, Anne van Kesteren wrote:

>
> On Mon, 30 Jul 2007 14:44:33 +0200, Ben Boyle  
> <benjamins.boyle@gmail.com> wrote:
>> http://dev.w3.org/html5/spec/Overview.html#the-root
>>
>> This seems fine to me.
>>
>> Unsure about the second note: doesn't xmlns="" put an element into  
>> the
>> "null" namespace in XML?
>
> It is about the namespace the xmlns _attribute_ ends up in. Not the  
> element on which it is declared.

I think the problem Ben is pointing out is that the last three  
paragraphs of the root element subsection (one normative paragraph  
and the two "green" notes are very unclear. (for authors and UAs). I  
think those should be rewritten into a single coherent paragraph that  
addresses the attribute names "xmlns" or "xmlns:*".

It would really help these discussion to stay focussed on the review  
in how it improves the draft. It should not just be about correcting  
a reviewers misstatements, but about how the draft could bee changed  
to avoid the confusion that may have led to the misstatement.

>
>> Not sure this note is even needed, maybe it
>> should say: In XML serialisations all elements must be declared in  
>> the
>> "http://www.w3.org/2000/xmlns/" namespace.
>
> No, they should be declared in the http://www.w3.org/1999/xhtml  
> namespace.

Yes, but how can we change the draft to make the use and treatment of  
xmnls (and xmnls prefixed) attributes clearer.

>> May be worth making a note that inherited attributes (particularly
>> @lang and @dir) can (should?) be declared on the root element.
>
> Requiring that just leads to WYSIWYG editors putting them in some  
> boilerplate making lang= even less useful than it is now. (This is  
> already happening :-(.)

Instead of just not requiring those attributes, we could also require  
those attributes have author specified values. We could give advice  
to authoring UAs that they should retrieve the values from these  
either from their own preferences or from the system preferences for  
the author. Every author has a primary language set in their  
operating environment or in their authoring tool environment. That  
language has a directionality. Those attributes can easily be set  
from that information. Providing a dialog on "new" can also help the  
author change those values on a case-by-case basis.

>> I hope it's becoming clear how confusing these implementation
>> specifics will be for authors, how they get in the way of
>> understanding the markup rules. I appreciate they all have a purpose,
>> but I'd rather those details were stuffed in appendices where I'd  
>> only
>> encounter them if I really dug into details.
>
> Specifications are meant to cover the nasty little details. If a  
> specification were just an authoring guide it wouldn't be of much  
> use to picky authors who'd like to know how things are actually  
> working. You'd just have another HTML 4.

Certainly, specifications cover the nasty details. However those  
details can be covered from multiple perspective. Right now the draft  
only presents those nasty details from the UA perspective and not the  
author perspective. We should not shy away from presenting both  
perspective. For example, in the microsyntaxes section the current  
draft explains to a UA how to parse out various data types given a  
string. We should also provide normative language for authors to  
create such a string that will contain the authors intended data  
types. This doesn't have to be written in less detail. It just has to  
be written so that an author can comprehend the norms for authoring  
certain data types. This is an entirely different issue from whether  
we create other document tutorials or whatever.

Take care,
Rob

Received on Monday, 30 July 2007 17:37:09 UTC