Re: Decentralised extensibility idea (ISSUE-41)

Toby Inkster, Fri, 15 Jan 2010 16:13:43 +0000:
___
> Leif Halvard Silli wrote:
___
>> But thanks to HTML5's freedom w.r.t. where @id/@class might appear, 
>> then a perhaps more - as you said - "HTML-ish" (not to say 
>> "Twitter-ish") option would be this:
>> 
>> <head >
>> <link id=CarML rel=profile href=http://example.com/CarML/html5 >
>> </head>
>> <span profile="#CarML" class="Car">Mazda</span>
> 
> I don't think adding an extra level of indirection would be especially
> helpful. If it's supposed to prevent repetition, then perhaps my
> original message wasn't clear enough.
> 
>  <html profile="http://example.com/CarML/html5">
> 
> would automatically license class="Car" and associated data-* attributes
> to have their CarML meaning everywhere in the document. So repetition of
> the profile is rarely needed.

OK, I see your point!

But let's say that CarML was more all encompassing than I wanted. For 
example, let's say that it contains "Colour", but that I do not want 
that each time I use "Colour" within my document, then an application 
which supports CarML, will interpret it as if I meant "Colour" as 
defined in CarML. Let's say that all I wanted to use was the element 
"Car".

So, instead of the indirection, perhaps pointing only to the fragment 
"#Car" within the CarML spec could have the desired effect?:

<html profile="http://example.com/CarML/html5#Car">
 
Meaning that if I wanted to use "Car" and "Brand" only, I could would 
use several profiles:

<html profile="http://example.com/CarML/html5#Car

               http://example.com/CarML/html5#Brand">

?

Or if the CarML spec was sectioned so I could pick just "Car" and 
"Brand" with one URI, then this:

<html profile="http://example.com/CarML/html5#Car+Brand">

(Or, perhaps a certain URI design - such as the one above 
[profile="http://example.com/CarML/html5#Car+Brand]  - could mean that 
actual sectioning would not be necessary?) 

This proposal would also affect what we discussed here:
___
>> I think  - when necessary - to separate "Car" from CarML and "Car" from 
>> MyML, there should be some prefix option. I don't know, but perhaps 
>> simply like this: ?
___
> There are three situations you could be in when attempting to mix
> otherspecs:
> 
> 1. One otherspec defines class="Car" and the second otherspec doesn't
> define any meaning for class="Car" at all. In this case, user agents
> implementing the first otherspec will understand it and user agents
> implementing the second will ignore it. No problem.
> 
> 2. Both otherspecs define class="Car" in such a way that (for your own
> use case at least) they are equivalent. In which case:
> 
> <html profile="http://example.com/CarML/html5

> http://example.com/MyML/html5">
>   ... <span class="Car">Mazda</span> ...
> </html>
> 
> Should just work in both otherspecs. No problem.
> 
> 3. Both otherspecs define class="Car", but with conflicting
> interpretations. In this case, it is impossible to apply both otherspecs
> to the same HTML node. This does cause a problem: scoping the profile
> attribute can usually help here, but at other times, you'll just have to
> drop compliance with one of the otherspecs.

For 3), if the document needs to use "Car" from both specs, then indeed 
it would be a problem, whenever scoping for some reason would 
impossible to use - but I agree that we'll just have to live with that 
problem. But if you would only need to use "Car" from the one spec, 
then I think  a profile URI which pointed to a seciton of MyML which 
did not contain "Car", could be an option. Thoughts?

> Philip Jägenstedt wrote:

>> I don't think this is a very good idea, as data-* are always hidden
>> and not suitable for marking up content that is visible in the page.
> 
> You are mistaking my proposal for a method of embedding data into a
> document. The proposal is not intended for embedding the kind of data
> that Microdata or RDFa embed; rather it's a general purpose extension
> point that other standards ("otherspecs") could use.

+1
-- 
leif halvard silli

Received on Friday, 15 January 2010 17:16:43 UTC