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

On Sat, 2 Aug 2008, Julian Reschke wrote:
> Ian Hickson wrote:
> >
> > It solves the problem of chattiness, but unfortunately causes such huge
> > problems for authors in terms of understanding it that it's probably not
> > worth it. There are other ways of avoiding chattiness though, that don't
> > require prefixes nor have the problems associated with prefixes.
> 
> I do not agree these are "huge" problems.

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


> Yes, people are confused by prefixes. But people are also confused by 
> other things, like multiple classes in a single class attribute. People 
> are also confused about microformat parsing and class value inheritance.
>
> The answer is test cases, bug reports and education.

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.

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


> > For instance, there's no reason we need to use a URI. People could 
> > just do this instead:
> > 
> >    <span class="intertwingly.net-price">
> > 
> > ...or even:
> > 
> >    <span class="intertwingly-price">
> > 
> > ...or some such. It's highly unlikely that two groups with similar 
> > domain names would both come up with clashing names.
> 
> Oh really? That may work well for "intertwingly", but less well for 
> other domains.

Obviously authors should decide how much the guarantee of uniqueness 
matters to them, and work from that. Sometimes the TLD will be enough 
(e.g. say in .mil one might have a mechanism for minting unique class 
names across the entire .mil domain space), sometimes the path will be 
necessary too (e.g. in a Geocities-like environment).


> > We could add:
> > 
> > Authors may use their domain name, or some other identifying or unique 
> > information, as a way to disambiguate class names they invent from 
> > class names used by other people. This allows class names invented by 
> > multiple groups to eventually be used on pages together, without 
> > clashes. Author inventing class names should avoid including domain 
> > names or other identifying information that would clash with another 
> > author's.
> > 
> > For example, an author at example.org could use class names like 
> > "price.example.org" or "currency.example.org", and an author at 
> > example.com could use class names like "com.example.price" and 
> > "com.example.stock". Their "price" class names are then 
> > distinguishable. However, it would be considered inappropriate for the 
> > author of example.org to then invent a class name 
> > "com.example.quantity" without first getting permission from the 
> > author of example.com.
> > 
> > Would that satisfy your request?
> 
> 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.


> > > > With HTML5, you can even have custom attributes on your element:
> > > > 
> > > > <span class="price" data-currency="XCD">$7.99</span>
> > >
> > > If the currency information is for anything except scripts within 
> > > the page, it would be an abuse of that attribute, right?
> > 
> > Not necessarily scripts, just not something that is to be used by a 
> > user agent. It's for private data, but that doesn't mean it can't be 
> > used by tools specific to that site or its affiliates.
> 
> Yet, I want it to be possible that it gets used by user agents.

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.


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

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.


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


> > [...] Microformats it supports) and in addition is frankly just a bug 
> > in GRDDL (authors rarely use the profile="" attribute when using 
> > Microformats so to work with real content GRDDL should be designed to 
> > handle content irrespective of the profile="" attribute). In any case, 
> > <link rel=profile> [...]
> 
> It seems you're mixing up the base GRDDL specification (a W3C 
> Recommendation, <http://www.w3.org/TR/grddl/>) with specific 
> microformat-specific use cases mentioned in the GRDDL primer (a WG note, 
> <http://www.w3.org/TR/grddl-primer/>).

What I said above applies to all metadata profiles, not just Microformat 
ones. I guess I should have been more general in my statements.


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


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


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

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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 2 August 2008 09:52:49 UTC