Re: Extensibility strategies, was: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

Ian Hickson wrote:
> | As the author of an O'Reilly book on XForms, I can report that 90% of 
> | the technical questions from readers involve confusion related to 
> | namespaces.
>  -- http://www.w3.org/2004/04/webapps-cdf-ws/papers/verity.html
> 
> | Over the years I have worked with a good number of XML developers, 
> | ranging in skill from occasional user to expert. In almost every case I 
> | have found a lack of understanding of namespaces -- or, in the presence 
> | of understanding, hands-on confusion in working with and debugging 
> | namespace-related issues. 
>  -- http://www.ibm.com/developerworks/library/x-abolns.html
> 
> My own experiences looking at real world markup correlates with these 
> findings -- pages that attempt to use namespace prefixes for whatever 
> reason frequently have egregious mistakes, far more so, relative to total 
> usage, than any single other feature I have examined.

My own experience with real-world markup in the XML space (almost 10 
years) indicates that those people that are confused first can be 
educated and will learn.

> ...
> One finds people confused about many things, but honestly I have rarely 
> found any concept that causes non-geeks more confusion than the concept of 
> indirection. Namespace prefixes are nothing more than indirection, that's 
> their entire reason for being.
> ...

Class names use indirection as well.

 > ...
> When designing a language, avoidance of features known to be 
> disproportionately confusing to users of that language is important.
> ...

It depends on what the price of avoiding these features is.

> ...
>> Not at all. I'd like those to be URIs. I know you don't like them for 
>> this purpose, but they have the advantage to be simple detectable.
> 
> The above doesn't preclude your use of URIs if you so desire.

Disambiguation only works *reliably* if the format is well-defined.

> ...
> There is currently no mechanism for including non-visible proprietary 
> metadata intended for use by user agents in HTML documents without 
> discussing the extension with user agent vendors and the wider Web 
> community, but I posit that this is a good thing. We don't want user 
> agents inventing their own attributes without working with interested 
> parties to make sure their feature is well designed.
> ...

Again: who is "we" in this case? Certainly not the HTML WG.

As a matter of fact, integration of RDFa-like features is in our charter.

>>> As far as I can tell, use of Dublin Core metadata rarely if ever uses 
>>> the scheme="" attribute. In fact insofar as I can determine from 
>>> reading RFC2741, there are no normative requirements on the use of 
>>> "scheme", it is purely at the whim of the author. So this doesn't 
>>> break anything. ...
>> It makes documents using them invalid.
> 
> No it doesn't, they are still valid HTML4 documents.

But I can't mix these extensions (which I *do* use, this is not 
theoretical) with HTML5 features. So basically you're saying: go away?

> In any case, are there any such documents? I cannot recall ever finding 
> any. I did some in-depth research on this when deciding what to do about 
> scheme="" several years ago.

Yes, there are. For instance, the web repository manager in SAP's 
Knowledge Management system parses them and exposes the property using 
the KM's Java API to other applications, and I know of SAP customers 
using it. These documents may not be world-readable, but that's no 
reason to break them.

>>>> Another one is GRDDL, and HTML5 breaks it by removing the profile 
>>>> attribute on head.
>>> GRDDL's use of the profile attribute is an abuse of the profile 
>>> attribute (it requires custom profiles, not the official profiles for 
>>> the [...]
>> I do agree that GRDDL could and should have been written without the 
>> profile dependency.
>>
>> However I'm not sure what you mean by "custom profile" -- I think GRDDL 
>> requires exactly one profile, which is used to opt-in to use the GRDDL 
>> transformation rel value.
> 
> GRDDL requires that the profile="" attribute point to a document that 
> announces an XSLT transformation program, as opposed to requiring it to be 
> the actual URL of the metadata profile used on the page.

As far as I can tell, that is incorrect. The only profile GRDDL (the 
base spec, <http://www.w3.org/TR/grddl/>) requires is:

   profile="http://www.w3.org/2003/g/data-view"

See example in <http://www.w3.org/TR/grddl/#grddl-xhtml>. The URI of the 
transformation program sits in a link/@rel=transformation href attribute.

 > ...
>>> [...] is available as a workaround if GRDDL's maintainers decide not 
>>> to actually fix the real underlying bug in GRDDL.
>> So you're saying that meta/@rel=profile is ok, but head/@profile is not?
> 
> No, I'm saying <head profile> is rarely used, never used appropriately, 
> and causes more confusion than it's worth, and has thus been removed, but 
> that people can use HTML's generic extension mechanisms to get the same 
> effect if they want to insist on doing things the wrong way.

Well, another point of disagreement.

>> If it has the same semantics, why disallow it, breaking existing specs?
> 
> GRDDL's use of profile="" is already broken (by design). Disallowing it 
> only made this problem more visible.

It is not "broken".

>>>> And hey, another one are microformats, which claim to require 
>>>> profile as well:
>>>>
>>>> "In hcalendar-issues, it is ACCEPTED that each microformat should 
>>>> have a profile URI, like the XFN profile." -- 
>>>> <http://microformats.org/wiki/profile-uris>
>>>>
>>>> I realize this doesn't reflect reality, but then why is nobody 
>>>> fixing the web page???
>>> My understanding is that this is present because HTML4 theoretically 
>>> requires profile="" and HTML5 isn't done yet.
>> How does HTML4 "require" profile? Please elaborate.
> 
> # [...] specifying meta data involves two steps: [...]
> # 2. Referring to a profile where the property and its legal values are 
> # defined. To designate a profile, use the profile attribute of the HEAD 
> # element.
>  -- 7.4.4 Meta data, http://www.w3.org/TR/html4/struct/global.html#h-7.4.4
> 
> If you read further you'll see that the only allowed values of <meta name> 
> and so forth in HTML4 are those defined by the metadata profile given by 
> the profile="" attribute.

The microformats I've used (such as vcard) do not even use the meta 
element, so who exactly is this relevant?

> (Nobody actually does any of this, of course, and HTML4 does a woefully 
> inadequate job of actually explaining how it's supposed to work, which is 
> why after first trying to define profile="" in much more detail, it was 
> eventually just removed from HTML5 altogether.)

I agree that the definition in HTML4 is problematic. I also agree that 
the mechanism itself is problematic.

However it is used, and just removing it is the wrong answer. Let's 
either fix it, or deprecate it and replace it by something better.

A necessary precondition for that is to understand how profile currently 
is used. I have the impression that this understanding currently isn't 
there.

BR, Julian

Received on Saturday, 2 August 2008 10:31:02 UTC