- From: Mark Birbeck <mark.birbeck@formsPlayer.com>
- Date: Wed, 23 Jan 2008 21:54:42 +0000
- To: "W3C RDFa task force" <public-rdf-in-xhtml-tf@w3.org>
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