- From: Mark Birbeck <mark.birbeck@formsPlayer.com>
- Date: Tue, 15 Jan 2008 16:28:54 +0000
- To: "Ben Adida" <ben@adida.net>
- Cc: RDFa <public-rdf-in-xhtml-tf@w3.org>
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