Re: capturing reserved keywords in @rel

Hi Ivan,

> > So the first question is where are you proposing to place the
> > pre-processing step? (In the spec, I mean.)
> >
>
> Nowhere:-)
>
> I do not think that this pre-processing step should be part of the spec.
> It is a reasonable way of implementation (my implementation has,
> essentially, the same general feature built-in), but it is not a spec issue.

Right...I agree. But that does mean we have gone full circle, since
that's what we had before, when we agreed to defer the issue all that
time ago. The whole point of my suggestion at the time, was that we
would add the feature that we know we want to implementations, and
then we should work out later exactly how to write it up in the spec,
or whether it should be part of some other spec, such as hGRDDL, or
even (dare I say it?) CURIEs.

I'll come back to this idea at the end.


> I am actually lost. I thought Manu's proposal in:
>
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Jan/0152.html
>
> is a perfectly reasonable way of document this and put an end to the
> issue (and hGRDDL is _a_ conceptual way of implementing it, but that is
> not part of the document).
>
> What is wrong with Manu's stuff?

First, with respect to Manu, I don't know what this means:

  The http://www.w3.org/1999/xhtml/vocab# namespace is automatically
  applied to each predicate that is non-prefixed and exists in the
  http://www.w3.org/1999/xhtml/vocab# namespace.

It would need to be more precise than this, to count as "spec-ready text".

But to be fair on Manu, it's difficult to see how we _could_ be more
precise -- that's why I was all for moving this whole question outside
of the spec. (And you've just said that you don't think this should be
in the spec, anyway. :)

Anyway, this isn't what I've been trying to raise. The issue I keep
coming back to is what to do with the non-pre-processed values, i.e.,
those values that weren't in the list of XHTML link types. They will
still be sitting there in @rel and @rev, and whilst they _look like_
CURIEs, they are not. If we apply Manu's prose above, then we will be
left with a non-prefixed CURIE for "DC.Creator", for example, and that
will generate a triple.

So...

Everyone knows what they would _like_ to do with these values -- I've
heard "ignore them" plenty of times now. :) So all we need is some
"spec-ready text" that might achieve this.

To illustrate what I mean by being more precise, we could solve this
by, for example:

  * saying that @rel and @rev hold 'safe CURIEs', rather than CURIEs,
    and that when processing @rel, only CURIEs are processed (Ben
    doesn't like this approach because it reopens a closed issue, but
    it is important to realise that this is the only way to ensure that
    CURIEs are consistent throughout the spec);

  * or, saying that a CURIE actually doesn't have an empty prefix
    version, and so "DC.Creator" is simply not a CURIE, and so is
    ignored (I don't like this approach because it means our CURIE
    rules will be different to those in @role and @access).

But given that we can't get agreement on this, I think the best thing
is to take it out (as you say) but to define the preprocessing step as
being closely related to @profile.

By this last point I mean that XHTML already says that if you use a
LinkType value in @rel that is not referred to by a value in @profile,
it is invalid. So we could extend that somewhat, and say that the URL
of the profile is prefixed onto any 'matching' values (in the way that
"...#vocab" is added in hGRDDL), and then any unmatching values are
*completely removed*. This means that "DC.Creator" would be gone if
there is no appropriate @profile value, and therefore it could never
be confused with a non-prefixed CURIE.

Of course, the exact mechanism by which the correct DC prefix gets
attached to the correct values based on @profile would need to be
worked out, but pulling in a script in GRDDL fashion is probably what
Ben has in mind. So until it has been defined, "DC.Creator" will
simply be removed, and "next" and "license" will work fine.

But the key advantage of this approach is that it moves the issue out
of the RDFa spec, and into some pre-processing specification, and we
therefore don't need to touch our rules. "DC.Creator" remains a valid,
unprefixed CURIE, in all other contexts, but as long as we ensure that
it never gets to the RDFa parser when used in @rel, then there can be
no confusion. Which means that we don't need to say *anything* about
ignoring unprefixed values in the spec.

In fact, all we really need to do is add a note to the RDFa spec that
tells implementers that there is a need for a pre-processing step
which has the effect of normalising values with a valid profile, and
removing those that are invalid, to take into account legacy mark-up.
We could say that a future spec will define this in more detail, and
that for now an implementer should act 'as if' that pre-processing had
been performed.

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, 22 January 2008 12:53:37 UTC