W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > January 2008

Re: status of non-prefixed values in @rel

From: Ben Adida <ben@adida.net>
Date: Tue, 15 Jan 2008 08:46:53 -0800
Message-ID: <478CE37D.10502@adida.net>
To: Mark Birbeck <mark.birbeck@formsPlayer.com>
CC: RDFa <public-rdf-in-xhtml-tf@w3.org>

Mark Birbeck wrote:
> I think it is true that we don't have a resolution in the sense of
> everyone voting on a call, or whatever. But we did have strong support
> for my proposal.

We did indeed, but the reason we schedule votes is so we have a chance
to express opinions, change our minds, and finally "lock in" our
answers. After further thinking, I'm even more convinced that not
handling rel="next" (and specifically rel="license") is a problem.

> This is the approach that everyone agreed with at the time, since it
> deferred the problem. So although it's fair enough to say now that you
> probably shouldn't have gone along with it :) that does mean that we
> need to find a solution, and that is pretty difficult. (Which is, of
> course, why I proposed that we defer the question.)

I'm confused by this statement: after all, why do we need to mandate
some kind of mechanism for this? Why can't we just say "legacy values
are supported", end of story?

I think the complexity of the discussion has consistently been caused by
an attempt to make the legacy issue consistent with generic rules. How
about we say: it's not consistent, you'll probably have to write some
special-case code in there to consider legacy values, but frankly we
don't need to specify how that works. After all, legacy is legacy, and
we do have a follow-your-nose hook for it already: the XHTML spec.

> we 'enable' the use of our values in @rel in just the
> same way that one would normally do in XHTML, regardless of RDFa.

That is a good point, indeed, but that can be done no matter what the
URI, since the RDFa URI can simply "include" the XHTML vocab, since we
get to say what /ns/rdfa means.

> On top of this 'standard' use of XHTML, we could consider using safe
> CURIEs in @rel and @rev.

No, that issue we have resolved quite thoroughly:


> Finally, on @property, I think that it shouldn't use the legacy
> syntax. @property can just take CURIEs and that's it.

Right @property is just a CURIE, as per Issue 5 resolved above.

> <meta> can still support @name, which does *not* need to take CURIEs, which neatly
> demarcates 'legacy' values.

Are there legacy reserved words for <meta name="">? If so, I agree that
we should support those just like rel="next". And again, I don't think
we need to go mechanistic here: we just say what the prescribed output
is, and we can write it in the spec as:



rel="x" for x in (rel,rev,next,license,...)

is equivalent to


<meta name="y"> for y in (...)

is equivalent to

<meta property="xhvocab:y">


So, I think I agree 80% with you Mark: let's not try to find complicated
rules to make the legacy work. Where we may disagree is that, instead of
not supporting the legacy stuff, I'm proposing that we just say it *is*
supported through these equivalences that are XHTML-version-specific,
and the RDFa spec doesn't need to specify the details of how this
support is implemented.

Received on Tuesday, 15 January 2008 16:47:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:26 UTC