Re: capturing reserved keywords in @rel

Hi Ben,

> We should *not* consider hGRDDL as an official piece of the RDFa spec.
> I'm only trying to show how trivial it is to look for reserved keywords
> and prefix them so they can be picked up by the main RDFa parser (which
> otherwise ignores un-prefixed @rels). This approach is a pre-processing
> step, which may be how we want to word it.

Right...but what about the spec? As I keep saying, the tricky bit is
not writing code to do it, but putting it into the spec. Everyone
keeps saying this is easy, but still no-one has tackled the
specification side. :(

So the first question is where are you proposing to place the
pre-processing step? (In the spec, I mean.)

Second, once the pre-processing step has run, there may still be some
non-prefixed values left that were unmatched; since these are valid
CURIEs, what are you suggesting is done with them?

I'm sure the answer will be 'ignore them', but how, exactly? Some rule
somewhere needs to say that a different CURIE processing algorithm
needs to be applied to these values than those in other attributes.
Where would you put that rule?

Last time we discussed this there were proposals that we actually
redefine CURIEs to have a mandatory prefix, and that was why we ran
aground. And I'm very much against having differential rules, so I'm
trying to get specific here on how you would 'switch out' the values
that you want to ignore.


Not wishing to preempt any replies, but like to return to a suggestion
I made the other day, and see if you'd find it acceptable in
conjunction with your hGRDDL proposal.

I was saying that I would like to see us leave CURIE rules alone (or
if we change them, we change them everywhere), and instead modify the
definition of @rel so that it could take _both_ a safe CURIE _and_ a
LinkType. This seems right to me anyway, since we are dealing with an
attribute that already exists in XHTML, so we really shouldn't be
removing its old type.

So, for example, a @rel value might take something like the following:

  <link rel="license" href="..." />
  <link rel="[cc:license]" href="..." />

This uses safe CURIEs in just the same way as attributes like @about
and @resource.

You could still run your pre-processing step, with the minor
modification that matching values are converted to a safe CURIE, not
just a CURIE:

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

And in fact, since the default prefix is "...#vocab" then we wouldn't
even need to worry about the 'xh' prefix:

  <link rel="[:license]" href="..." />
  <link rel="[cc:license]" href="..." />

It also means that we don't need to worry about unconverted values,
since they will simply be non-CURIEs:

  <link rel="DC.Source" href="..." />
  <link rel="[:license]" href="..." />
  <link rel="[cc:license]" href="..." />

Our algorithms could be tweaked slightly to say that what we look for
in an attribute depends on the datatype of the attribute, and so in
the case of @rel we are only looking for safe CURIEs.

It's not perfect -- what is? :) -- but it does mean that CURIEs behave
the same everywhere, and it allows us to ignore the unprefixed values
that didn't match the list of XHTML types, but that we don't want to
be interpreted as unprefixed CURIEs.

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 03:11:44 UTC