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

On Sat, 2 Aug 2008, Julian Reschke wrote:
> > 
> > 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.

Education is expensive. Why not just make it unnecessary?


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

How so?


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

The price of explicit names is verbosity. It's a small price to pay, in my 
opinion. (Bandwidth is mostly unaffected as common strings compress well.)


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

Why? Are you concerned that people using different dismabiguation schemes 
would somehow come up with clashing names? How would that happen? Could 
you give an example?


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

So you're in favour of the behaviour seen in the browser wars where people 
just made up their own tags all the time?

I am not.


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

If you are using the scheme="" attribute for Dublin Core metadata, could 
you point me to the part of the spec that defines what the semantics of 
scheme="" values is? How would an independent Dublin Core processor know 
how to interpret the scheme="" values?


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

Is such content ever made available to a non-SAP user agent that is 
expected to process that data? Could you elaborate with concrete examples? 
I would love to learn more about this. It is the first I have heard of a 
real use of scheme="" and any information, examples, etc, you could give 
would be very useful. (If you don't want to do this publicly, feel free to 
send me exampls privately. If you would like me to sign an NDA, that can 
be arranged.)


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

My point is that this is incorrect use of profile="". If you use dublin 
core metadata names, you should have a dublin core profile value, not a 
GRDDL profile value.


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

Which point do you disagree with? As far as I can tell all of the above 
are objectively verifiable.

<head profile> is rarely used -- verified with samples of billions of 
pages.

<head profile> is never used appropriately -- the only actual use I've 
heard of is GRDDL, and it uses it inappropriately.

it causes more confusion than it's worth -- this conversation itself is 
clearly evidence of that.

has been removed -- it's not in the spec

people can use HTML's generic extension mechanisms to get the same effect 
-- the two methods are semantically equivalent, and can even be 
mechanically converted to each other, so this is true too.


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

It violates the semantics put forth by HTML4.


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

I believe that it is assumed that HTML4's vagueness was meant to imply 
that profiles apply to classes as well. One would have to ask the 
Microformats community for a better explanation.

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

Received on Saturday, 2 August 2008 20:03:34 UTC