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

Trying to focus on how to address your use case...

On Tue, 5 Aug 2008, Julian Reschke wrote:
> 
> If you think it is so unlikely, why not make a statement that something 
> that parses as a URI must be a URI under the control of the party 
> minting the identifier?

Would this resolve your use case?


> > (They have other problems as well, as I said recently and as you 
> > quoted above, e.g. people get confused with relative URIs, people who 
> > use HTTP URIs -- most people, in practice, for namespaces -- get 
> > confused about when or how to derefernce them, etc.)
> 
> You don't dereference them (automatically). Put that into the spec, and 
> there will be no confusion.

Unfortunately, saying that doesn't help in practice. q.v. the W3C's load 
problem due to people dereferencing URIs that shouldn't be dereferenced.


> So, out of curiosity, what would be a better design for CSS?

I have no idea. People have a big problem with the indirection of having 
the semantics/structure in one document and the style in another. I don't 
know how to solve this, though, as the split is too advantageous to lose.


> > How do you propose to have a distributed extension system with URNs, 
> > if you're not using the domain name system to guarantee uniqueness? 
> > Aren't you just trading one central repository (the HTML WG) for 
> > another (the URN registry)? Could you elaborate on how you see this 
> > working?
> 
> I recommend reading the URN specs. For instance, the namespaces below 
> "urn:isbn", "urn:ietf" and "urn:uuid" are controlled by different 
> entities (or for the case of UUIDs not controlled at all).

As far as I can tell, none of these would allow you to invent your own 
vocabulary without first contacting a centralised registry.


> In particular, the "tag:" URN scheme solves the DNS issue by adding a 
> timestamp

That seems just slightly more verbose than an HTTP URI.


> I'd prefer
> 
> - the spec to give rules for the formats of these names, so clashes are 
> avoided (if you use a URI, use one you have authority over), and
>
> - a more compact syntax (be it QName, CURIE, whatever).
> 
> And of course I'd really prefer a mechanism that uses the same syntax as 
> in other markup languages, obviously (or is as close to them as 
> possible).

Are all three of these requirements absolute requirements, or would you be 
satisfied with, say, just the first?

Here are my requirements:

 - that the extension mechanism have a fallback mechanism for 
   accessibility, e.g. so that you can give a "nearest equivalent HTML 
   element" for each extension.

 - that the extension mechanism be easy to use, e.g. not use any kind of 
   indirection, not split the names up to distant parts of the document

 - that the mechanism work or fallback gracefully in legacy user agents

 - that the mechanism allow authors to use whatever naming scheme is most 
   convenient for them

I don't think we can hit all seven requirements simultaneously. If you 
have any proposals, I'm certainly eager to hear them.

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

Received on Tuesday, 5 August 2008 11:30:53 UTC