Re: status of non-prefixed values in @rel

HI Ben,

Just a quick note on the motivation for my proposal, and then some
comments on another possible way out of this.

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. So I'll just clarify what exactly my proposal was.

At the time we were essentially going round in circles. Everyone knew
what we wanted to achieve, but there was no proposal that made it work
and was consistent with everything else we were doing. For example, we
can say that we run a 'preprocessor' to convert 'next' into 'xh:next',
but what do we do with 'foo'? Do we remove it, or ignore it? Some RDFa
parser may want to use it -- which is ok if it's not placed into the
default graph -- so we should really pass it through. But then we have
to define how "foo" differs from the CURIE that looks exactly the
same.

And on it goes...

So, my proposal was simply to defer the question to a later date,
since it was taking up a lot of time. I wasn't saying we couldn't
solve it given enough thought and energy, and I wasn't saying that
parsers shouldn't do something with @rel="next", today. But what I was
saying was that since this is essentially a legacy question, we should
put it in the legacy bucket to be solved later.

So @rel=":next" will work no matter what solution we come up with in
the future, but @rel="next" will only work at the moment through some
kind of 'magic' that we haven't yet defined.

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.)

However...

As I mentioned on the call the other day, there may be a solution tied
up with @prefix. If we were to use the 'XHTML vocab' URL for the
@prefix entry, instead of the RDFa namespace (which as I raised in
another discussion doesn't strictly mean anything in an XHTML
context), then we 'enable' the use of our values in @rel in just the
same way that one would normally do in XHTML, regardless of RDFa. This
means that 'by definition' @rel="role" is legitimate, and @rel="foo"
is not. This also gives authors the possibility of adding other
values.

On top of this 'standard' use of XHTML, we could consider using safe
CURIEs in @rel and @rev. That's probably controversial, but if we are
looking for a solution it has to be considered. After all, the whole
point of 'safe CURIEs' is to disambiguate in situations where a CURIE
could be mixed up with a non-CURIE, and @rel seems to me to be one of
those places.

Finally, on @property, I think that it shouldn't use the legacy
syntax. @property can just take CURIEs and that's it. <meta> can still
support @name, which does *not* need to take CURIEs, which neatly
demarcates 'legacy' values.

Just some thoughts, just in case you decide to 'undefer' this, and try
to find a solution. :)

Regards,

Mark

On 12/01/2008, Ben Adida <ben@adida.net> wrote:
>
>
> Hi all,
>
> I've been tracing the issue of non-prefixed, reserved-word values for
> @rel, and, from what I've found, there's certainly a thread that
> justifies Manu and Mark's memory, and where I contradict myself. That
> said, we then all approve the test cases in December, so we have all
> contradicted ourselves :)
>
>
> The history is:
>
> - a thread on 10 October where Ivan, Elias, Manu, and Shane seem to be
> in agreement (or at least to not express an issue) with a proposal I
> phrased that rel="next" yield a triple through something like
> pre-processing.
>
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0082.html
>
>  (the issue in that thread seems to be about what happens to @property)
>
>
> - a thread on 11 October, where Mark initially points out a problem for
> CC if we don't support rel="next", then in another email proposes that
> we switch to ":next", and Manu agrees, and I agree. We leave open the
> possibility that parsers will generate something for rel="next". Shane
> disagrees strongly. I disagree strongly with Shane.
>
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0106.html
>
>
> - test cases 61 and 62, which we all approved on December 13th
>
> http://www.w3.org/2007/12/13-rdfa-minutes.html
>
> and which specifically test for rel="next" and rel="prev", and we all
> approve it.
>
>
> So, it appears we don't have a resolution.
> In other words, this issue is still open.
>
> I'm going to spend some time thinking about what my take on this is. My
> initial feeling is: re-reading the 11-October thread, I am surprised by
> my own endorsement of ":next". As Creative Commons rep, I should never
> have supported the proposal that rel=":next", since that does indeed
> make things very difficult for Creative Commons, as per Mark's comment!
>
> On the plus side, it seems the issue isn't that I didn't record the
> resolution... it's that we didn't have one: the discussion was preempted
> by the more important chaining discussion, and then the holidays.
>
>
> -Ben
>
>


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Tuesday, 15 January 2008 16:29:00 UTC