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

Ian Hickson wrote:
>> 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?

If you can make it unnecessary without suffering from other drawbacks, 
like chattiness, unreliable disambiguation and unnecessary mapping 
problems to other specs, fine.

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

It's first level indirection in that you specify a class name, instead 
of adding the style information in place. In addition, it uses 
inheritance with exceptions, plus cascading, and - in HTML5 - scoping.

I'm mystified how a web developer can get *that*, and fail to understand 
prefixes. Sorry.

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

Of course that could happen. For instance, when using domain names, is 
the TDL right (URI) or left (Java packages). And so on.

What if you don't have a domain name, and prefer a UUID. Or a URN? Or a 
date-stamped URI (tag: URI scheme)? URIs give you the choice.

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

I am in favor of being able to use new vocabularies without getting the 
WHATWG's or the W3C's approval first. The price for that is that I have 
to put them into a separate namespace, and that is totally fine. It 
works everywhere else.

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

I can't answer that, and that is a problem of that standard. That still 
don't gives us the mandate to simply drop the attribute.

Also, HTML4 says the interpretation depends on the profile attribute, so 
again, pages can opt into a specific behaviour if they choose to do so.

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

The system uses the RFC 2731 format to embed properties into HTML, and 
exposes them just like properties as in any SAP KM document. It's used 
by UIs, crawlers, rating systems, page navigation and so on.

SAP customers can choose to expose SAP KM systems as public portals, but 
I'm not sure this is widely used.

As I don't work anymore in that project, I can't give you any additional 
information besides that.

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

And my point is that you apparently still have trouble distinguishing 
between GRDDL itself and some applications of it. You can use GRDDL 
without even going near Dublin Core, or meta elements.

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

GRDDL uses profile appropriately.

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

No, it doesn't.

It's also used for hCard, you recall? Yes, many authors leave it off, 
but it is recommended to use it.

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

I think it would be unfair to use the fact that you seem to be confused 
about GRDDL vs profile as data for making a decision.

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

In which case it's harmless to keep it.

If you insist on removing it, then please:

- get WG consensus to do so,

- explain to HTML4 users the replacement strategy,

- work with the other standards groups (in this case GRDDL) to get the 
spec updated to use the other format.

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

If you really believe that, then please explain what's wrong with it.

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

I don't see anything in HTML4 suggesting that, but maybe I'm looking in 
the wrong place (<http://www.w3.org/TR/html4/struct/global.html#profiles>).

What's clear is that the microformats community seems to have trouble 
dealing with profiles; some of their pages recommend using them 
(should-level), but then their test cases don't use them (I asked about 
that several months ago, and didn't get a reply: 
<http://microformats.org/discuss/mail/microformats-dev/2008-May/000509.html>).


BR, Julian

Received on Sunday, 3 August 2008 11:28:54 UTC