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

Ian Hickson wrote:
>> If you can make it unnecessary without suffering from other drawbacks, 
>> like chattiness, unreliable disambiguation and unnecessary mapping 
>> problems to other specs, fine.
> 
> Using a domain name followed by a hyphen followd by a word seems to solve 
> all of these simply.

If a domain name would be sufficient. So how many people within, for 
instance, Google, would want the ability to mint names, and how would 
you coordinate them?

>>> 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.
> 
> Oh for styling. Authors have had huge problems with that. It's actually 
> quite humbling to try to teach CSS to someone who hasn't ever learnt the 
> way of the Web, because they never ask "How do I make headings red?" they 
> ask "How do I make this piece of text red?".
> 
> The indirection of class names in CSS is a huge problem too.

Indeed. But people learn it.

>>> 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.
> 
> Could you actually give an example where this could happen? I haven't been 
> able to find a case where an actual clash could happen.

I'm pretty sure it can easily happen now that new restrictions on new 
TLDs have been more or less removed.

> Consider that even without any sort of disambiguation mechanic other than 
> just picking unusual names, Microformats has had no serious problems with 
> clashes. If you add domain names to the same thing, the problem really 
> becomes moot.

The microformats process does not scale. It "works" because it simply 
rejects proposals that do not look "common" enough, which of course 
reduces the number of potential clashes significantly.

That being said, clashes have occurred (what does the "title" class name 
stand for?), and it's also a known problem that you get in trouble once 
you want to nest information.

> It's like saying that you can't use checksums for disambiguating things 
> because you might have a clash.

Obviously it depends on the quality of the checksum.

>> 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.
> 
> class="C4E15D82-61A2-11DD-977B-B4AD55D89593"
> class="isbn:0674003810"
> class="ian@hixie.ch,2008-08-03,category"
> 
> None of these are ambiguous. They don't even have to use the same scheme 
> -- since they're all completely opaque, so long as you generate something 
> that is unambiguous, you will know that it can never clash with someone 
> else's. No need for URIs.

I disagree. For instance, an abbreviation such as "isbn" can be 
ambiguous. Just because *today* you and I agree what "isbn" likely 
means, doesn't mean everybody else shares that understanding now or in 
the future.

Just relying on that kind of understanding is risky: for instance, the 
first thing that comes to my mind when I hear "XDR" has changed twice in 
the last 10 years.

 > ...
>>>> 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.
> 
> If the price for that is that you have to use a syntax intended for this 
> use, which is in a different _syntactic_ space than the language's main 
> vocabulary, is _that_ an acceptable price?

Not sure what exactly you mean by "syntactic space". Namespace-qualified 
elements *are* in a different space, right?

>>> 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.
> 
> Ok, well, until someone can tell me what the attribute actually does, and 
> show that's there's a real, widespread need for it, let's not add it.

I personally think that the WHATWG started with the wrong default. A 
revision of something as important as HTML4 should use a "by default no 
change" strategy.

The attribute is totally harmless (just like profile), and the cost of 
keeping it in the language is definitively smaller than fixing 
everything that currently uses it.

> ...
>> 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.
> 
> Since we've also not included the profile="" attribute...

Sic.

> We have other mechanisms now that are much more flexible for including 
> private metadata of all kinds, e.g. data-*.

In this discussion, I'm interested in *public* metadata.

>> [GRDDL]
> 
> The GRDDL maintainers should make the following changes to GRDDL:
> 
> 1. Don't require profile="http://www.w3.org/2003/g/data-view" to support 
>    link rel=transformation.
> 2. Don't require transformations to look for profiles before applying 
>    their transformations.
> 
> Having done this, you now no longer need profiles to be declared, without 
> losing any functionality.
> 
> We're not keeping profile="", evidence is overwhelming that authors rarely 
> use it and, if they try, use it incorrectly. We're not including things 
> that are much more widely used (e.g. <font>). The bar for adding a feature 
> to HTML5 is high. profile="" doesn't even come close to qualifying. It's 
> not even actually solving a problem that needs solving, it's just a way to 
> declare something that you can just assume anyway. Indeed, it's similar to 
> a DOCTYPE declaration.

I do agree that GRDDL could easily work without profile being used to 
opt into the rel=transformation semantics. Potentially the concern was 
that there's no working relation value registry, so adding that piece of 
information would make it more strict. This issue could be resolved by 
registering the transformation rel value once we have a registry, and 
the IETF link header internet draft works towards that goal.

That being said, again: GRDDL is not "broken" with respect to this.

Point 2: transformations in general are not required to look for 
profiles (pointer?). Again, are you mixing up GRDDL (the base spec) with 
GRDDL use cases for microformats?

>> If you insist on removing it, then please:
>>
>> - get WG consensus to do so,
> 
> http://lists.w3.org/Archives/Public/public-html/2008Jul/0354.html

So, no WG consensus so far.

>> - explain to HTML4 users the replacement strategy,
> 
> Do exactly what you did before, just without the profile="" attribute.

Did you check whether this breaks GRDDL processors?

> This is what most authors are doing anyway.

Are you talking about profiles for microformats, or profiles for GRDDL?

>> - work with the other standards groups (in this case GRDDL) to get the 
>> spec updated to use the other format.
> 
> http://lists.w3.org/Archives/Public/public-grddl-comments/2008JulSep/0003.html

Thanks for getting the discussion started. That should have happened 
before GRDDL became a recommendation.

BR, Julian

Received on Monday, 4 August 2008 07:14:57 UTC