Re: status of non-prefixed values in @rel

Hi Ben,

On 15/01/2008, Ben Adida <ben@adida.net> wrote:
> 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.

I'm well aware of that. However, it's unlikely that we would have
voted on my proposal anyway, since it wasn't intended to solve the
issue, but merely to put it on hold for this release of RDFa.

Anyway, it's unfortunate that despite plenty of airing of opinions, in
this case we _didn't_ schedule a vote. Which means that all of the
work that was done at the time has been wasted, because it seems that
we are now going through the whole discussion again.


> After further thinking, I'm even more convinced that not
> handling rel="next" (and specifically rel="license") is a problem.

I don't doubt that! But we need a solution, and since none seemed to
be forthcoming many months ago, I proposed that we shelve it. If there
is something concrete on the table now, that would be great. But I'm
not sure that there is.


> > 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?

The problem hasn't changed from what it was all those months ago:

As you rightly point out, it's easy to say that "next" and "prev"
work; we could do that by saying that some preprocessing step acts on
these values (which was our original plan), or we could even just say
that these values "just work". Either way, it's no big deal.

But that was never the problem. The issue we had to solve was not how
to make those values work, but how to define that other values *don't*
work. In other words, how do we say that "foo", which will have been
ignored by a preprocessor or will fall through the 'just works' net,
is _not_ to be processed as a valid CURIE.

Note that this is not the same as saying that "foo" is a useful
formulation, or that we want to parse legacy triples, etc., etc. This
is in effect saying, 'ok, we agree to ignore these values...but how
_exactly_ do we ignore them?' Or to put it yet another way, it's
simply about where the 'exception' to the CURIE structure should be
placed in our specification.

So, snce "foo" is a legitimate CURIE, to say that it has no effect in
@rel/@rev, we need to either:

 (a) say that @rel/@rev do not allow CURIEs that have no prefix and no
colon, or;

 (b) say that _no attribute_ allows CURIEs that have no prefix and no colon.

You may remember that there was some support for the idea that in RDFa
*all* unprefixed CURIEs would be made simply invalid (the second
position, here). But you might also remember that I was against that,
for a number of reasons.

The main reason was that as we go forwards, XHTML documents will
increasingly contain CURIEs in attributes that have come from other
specifications that have used CURIEs. For example, the @role and
@accesskey attributes both take CURIEs, so having one format for RDFa
CURIEs and another for other specifications' CURIEs is undesirable,
and would almost certainly get raised as an issue as RDFa passes
through last call.

But I was also against it because it seemed to be an overly 'strong'
reaction to the problem, since the issue only shows itself in the two
attributes, @rel and @rev; when it comes to @about, @property,
@resource, @instanceof, @datatype, and so on, we do not get this
problem.

So, the alternative might seem to be to just do something special with
@rel/@rev. But insisting that a value with no prefix and no colon be
regarded as an invalid CURIE *only* for @rel and @rev seems even more
inconsistent than the previous issue of making RDFa attributes behave
differently to @role and @accesskey.

I don't believe this is irresolvable, but you can probably see now,
why last time round I suggested that we simply defer the issue. :)


> I think the complexity of the discussion has consistently been caused by
> an attempt to make the legacy issue consistent with generic rules.

Indeed. :) That was the key point of the email in which I suggested
deferring the question -- that we should separate the two issues. But
the other reason I proposed that we defer the issue was that I felt
that people weren't addressing the complexity of the problem. Since we
were not really having a debate that grappled with the real issue, it
seemed best to just postpone the whole thing, rather than waste time
on it.


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

That would be great...if it wasn't for the fact that we are
overloading @rel and @rev to hold CURIEs, and in some situations a
CURIE can look like a 'legacy value'.


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

It's true that the connection between the @profile URI and the values
that it enables is not clearly defined in HTML/XHTML, but I don't see
why we want to use a namespace document for this, especially when
there is nothing to namespace. (We don't have prefixed elements,
attributes or values!)

But either way, we still have @rel="foo" as a valid CURIE, even if we
agree that it's a value we want ignored.


> > 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:
>
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Jun/0128
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Jun/0132
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Jul/0005

Sure. I'm certainly not desperate to put 'safe CURIEs' into @rel. But
since you are now saying that you'd like to see a solution to the
problem of using legacy values, I thought I'd try to be helpful. :)

The whole purpose of 'safe CURIEs' is to disambiguate CURIEs from
something else when it's not clear what is a CURIE, and what is not.
We devised them to disambiguate between a CURIE and a URI, since it's
difficult to tell the difference between a scheme and a URI mapping.
But we've never really looked at the situation where you can't tell
the difference between a CURIE that is simply a relative path, and a
simple string, which is the problem we have now with @rel and @rev.

So using 'safe CURIEs' is certainly the easiest way out of this. We'd
simply do what we do with @about and @resource; in both cases we have
attributes that can take either a 'safe CURIE' or a URI. But unlike
with @about and @resource where we process both syntaxes, with @rel
and @rev we can specify that we will ignore the non-CURIE values. So,
given the following examples:

  <link rel="[foaf:knows]" href="..." />
  <link rel="next" href="..." />
  <link rel="foo" href="..." />

The first example works because it works. :) The second example works
because the preprocessor converts it to this (and then ordinary
processing takes its course):

  <link rel="[xh:next]" href="..." />

and the third example is ignored since it's not a CURIE (because in
this context, a CURIE can *only* be a 'safe CURIE').

Note that this also means that when we come to pin down the
preprocessor in more detail, it could be possible to allow people to
define processing for other legacy values such as Dublin Core,
microformats, and so on.

As I said, I'm not desperate to see us go this way, and would still be
happy to defer the decision. But if you're keen to solve this now (and
I can understand that) then my feeling is that this is one of the few
solutions that I think would find general acceptance.

Obviously that would need to be put to a vote. :)


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

Right. I was merely trying to draw attention to the fact that the
problem only exists with @rel.


> > <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:
>
>
> =======
>
> LEGACY SUPPORT
>
> rel="x" for x in (rel,rev,next,license,...)
>
> is equivalent to
>
> rel="xhvocab:x"
>
> <meta name="y"> for y in (...)
>
> is equivalent to
>
> <meta property="xhvocab:y">
>
> =======

Right...but that unfortunately doesn't tell us how to *ignore* the
values we don't want.


> So, I think I agree 80% with you Mark: let's not try to find complicated
> rules to make the legacy work.

I wasn't looking for complicated rules...were you?

All I said (in the previous discussion) was that since this issue is a
tricky one, let's put it on the back-burner. It has now been brought
back to life, so either we put it back on the back-burner again (but
this time we record the fact, or vote on it first and _then_ record
the fact...whatever), or we find a solution. (But the solution we find
cannot be a simple trashing of the CURIE syntax.)


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

I understand what you are saying, but that simply isn't possible with
the syntax that we have at the moment.

Regards,

Mark

-- 
  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 23:30:45 UTC