Further changes to URI and CURIE processing description

Hello all,

I've just pushed up some more changes, the main ones being to deepen
further the explanation about how CURIEs and URIs are processed. I've
done this for a couple of reasons.

The first is that in the processing section there was a lot of
repetition to explain some of the common requirements. For example,
all URIs need to be resolved relative to base, using the algorithm in
RFC 3986, and this was repeated at every point in the processing model
rules. Also, if an attribute can take a CURIE then that must be
converted to a URI, which was again repeated.

So...I've changed the processing rules to simply say, for each
attribute 'obtain a URI according to section blah blah'. Then in that
section I look at how the URI is obtained; for example if it's @href
you just read the value straight, if it's @about you check for safe
CURIEs, and so on.

That all keeps the processing model section a bit leaner, as well as
giving a bit more space to elaborate more fully on how URIs are used,
and how CURIEs get converted. It also means that some of the things
that seemed specific before, are now applied to all uses of CURIEs.
For example, I've now explained what happens with non-CURIEs, which
before was only being applied to @rel (i.e., that they are ignored)
but now applies to all attributes (e.g., @about="[foo]" will not set a
new subject).

Having the extra space also allows us to draw implementers' attention
to key parts of the whole CURIE/URI set-up which were not drawn out
before. For example, I've taken the opportunity of having a separate
section to point out to implementers that they must take into account
that XML namespaces are locally scoped...obvious I know, but it's the
kind of thing that is important for smooth implementation.

Anyway, I'm flagging this up mainly to draw attention to the fact that
although there have been a lot of changes, they shouldn't have
affected the processing. If anyone thinks that the processing has been
changed in any way, then please flag it up, because it was not
intentional.

However, there is one place I have changed the meaning...and it is
intentional. :)

(Takes deep breath...)

I have slightly changed how @rel and @rev work. There should be no
difference in the _effect_ though, but the change is that the
algorithm converts tokens like "next" and "license" *directly* to
URLs. In other words, "license" is no longer a shorthand for
xh:license, it is a shorthand for "http://....vocab#license".

It will no doubt sound to most people as if I'm discussing how many
angels can fit on the head of a pin; if it does, that's good, because
it probably means that no-one is bothered either way.

But for anyone who is worrying, here is the rationale: the point of
the new section on "CURIE and URI Processing" is to explain how you
get URIs for creating triples. As far as the main processing model
section is concerned the world is only made up of URIs -- there is no
such thing as a CURIE, since they will have already been converted.

Some attributes can take both a URI and a CURIE, and in that situation
the URI simply bypasses the CURIE algorithm and just remains a URI.

It struck me that the same could be said of @rel and @rev; you could
say that @rel and @rev take EITHER a link-type OR a CURIE. If it's a
link-type (next, previous, license, etc.) then you might as well
convert it straight to a full URI. And if it's a CURIE...well, we know
what to do with CURIEs.

The problem with the previous approach of saying that "next" is a
CURIE...is, well...it isn't. Now that we've said that an unprefixed
CURIE is invalid, then "next", "license", etc. are simply not CURIEs.
The only way to make them work is to have the preprocessing step that
we've all talked about, but then it gets very odd -- we've defined an
attribute that takes values of a certain type (CURIEs) and then listed
some values that don't conform to that type ("next", "prev", etc.) and
then we're relying on an external process to come tidy everything up
and make it work!

However...

If we take a different approach and say that the definition of
@rel/@rev is conceptually along these lines:

  linktype ::= "alternate" | ... | "next" | ... | "up"
  rel ::=  linktype | curie

and then say 'link-types are processed by converting them to URIs',
then we're all done. We don't need a preprocessing step, since
everything is within the RDFa syntax itself. And we've kept the
mapping from linktype to URI outside of both CURIEs and the core RDFa
processing model

Anyway...chew it over...

And be warned that I am up against a tight deadline, so even if you
rant at me that this is a terrible change, I'll probably ignore you.
:)

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 Wednesday, 23 January 2008 21:55:08 UTC