Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel

Henri Sivonen wrote:
> If you have an interest in deploying it more widely, perhaps it would
> make sense to design for wider deployment instead of designing for XML
> only.

And as you know, we are very much exploring the @prefix route *because*
we're interested in HTML deployment. You've read me say this a dozen
times, so your arguments are now bordering on disingenuous. We're
looking into it, we're working on it, we're discussing with you and
others; I'm not going to have this argument again.

[...]

>> And when HTML5 features are deployed in browsers before they're
>> standardized and while many other folks are howling, is the HTML5
>> community not happy?
> 
> The HTML5 community tends to cheer when people deploy drafted HTML5 *as
> drafted*.

The keyword here being "draft." HTML5 *proposed* changes aren't approved
for either mime type, and in some cases they're gigantic changes (SQL in
the browser).

So again, enough with the holier-than-thou attitude. We're all trying to
improve the web, and oftentimes that means getting ahead of the spec.

>> Rather, Dublin Core suggests a prefix-like approach: dc.title,
>> dc.creator, etc... OpenID does the same thing. eRDF does the same thing
>> *and* uses indirection to define its prefixes.
> 
> So why doesn't CC+ use cc.foo?

Well, CC uses RDFa because ... see the next question.

Why doesn't RDFa use "cc.foo"? Because Dublin Core, OpenID, and eRDF use
the "prefix.*" notation with a list of *assumed* prefixes, not an
extensible list. So we chose not to conflict with their syntax by
picking a syntax that is already associated with URI expansion, and URIs
are crucial, in our opinion, for extensibility.

> Why doesn't CC+ use eRDF?

High level: eRDF is not expressive enough (can't make a statement about
*items* on a page) and not self-contained enough (prefixes have to be
defined in the HEAD).

[...]

> GRDDL uses profile for two distinct things:
>  1) to authorize rel=transformation to be recognized
>  2) to dereference for transformation autodiscovery via profile
> documents that may or may not link to a transformation.
> 
> Point #1 can be addressed by a spec such as text/html authorizing
> rel=trasformation to be recognized as a well-known token without profile
> (i.e. making the processing similar to rel=next or rel=canonical).

The issue is not about what you can do to retroactively hard-wire GRDDL.
The point is how @profile *has* been used in the past, and thus how it
probably should continue to be used in the future.

> I think point #2 (i.e. following your nose with canonical URIs) is a
> design bug due to the scalability problems demonstrated already by DTD
> URIs even though DTD URIs in theory aren't URIs-as-identifiers but
> URIs-as-locators.
> http://hsivonen.iki.fi/no-dtd/

I strongly disagree.

> HTML4 only uses profile in theory. I'm interested in compatibility with
> text/html rel as it has been practiced prior to RDFa.

I understand the desire to consider practical uses when designing new
things. But it sounds like you want to consider rare practical uses
while also ignoring uses *specified* by w3c in the past. I don't think
that's the right way to move forward.

Assume we change @xmlns to @prefix: what precisely are the issues that
remain with "how things have been practiced?"

-Ben

Received on Thursday, 5 March 2009 00:11:30 UTC