- From: Mark Birbeck <mark.birbeck@formsPlayer.com>
- Date: Tue, 11 Sep 2007 16:50:48 +0100
- To: "Shane McCarron" <shane@aptest.com>
- Cc: "Ivan Herman" <ivan@w3.org>, "W3C RDFa task force" <public-rdf-in-xhtml-tf@w3.org>
Ivan/Shane, Thanks for your comments. You're not actually "disagreeing" with me though, since I put forward two proposals. :) I didn't think you'd go for the one I was favouring, but I thought it worth a punt. However, Shane is right that the side-effect that comes about when changing the default namespace--that @rel="next" ceases to be an XHTML predicate--is best avoided, not least because it means that there will be a difference in interpretation between RDFa and non-RDFa processors. (But also because it breaks with the notion of trying to avoid affecting the host language too much.) However, there is still a clarification that needs to be made, which is why I raised the issue, although I think I've got sorted now. What I now have in the syntax document is this: <blockquote> CURIEs can be used in any language, including non-XML languages. Any language that wishes to make use of CURIEs must provide a context which consists of: * a set of mappings from prefixes to URIs (for example, <code>p:r</code>); * a mapping to use with the default prefix (for example, <code>:r</code>); * a mapping to use when there is no prefix (for example, <code>r</code>); * a mapping to use with the '_' prefix, which is used to generate unique identifiers (for example, <code>_:r</code>). When CURIEs are used in RDFa in XHTML, the context is set as follows: * the prefix mappings are provided by the current in-scope namespace declarations of the [current element] during parsing; * the mapping to use with the default prefix is the current default namespace; * the mapping to use when there is no prefix is <code>http://www.w3.org/1999/xhtml#</code>; * the mapping to use with the '_' prefix is not explicitly stated, but should be chosen by the processor to ensure that there is no possibility of collision with other documents. </blockquote> This fits with most of the uses of QNames that I can find. For example, XSLT says (for some attributes) that non-prefixed QNames are *not* expanded relative to the default namespace, whilst in some XML Schema attributes they are. In our case we've said that a CURIE with no prefix is expanded, but it will be exanded based on a fixed mapping, i.e., the XHTML namespace. (I've added '#' but we can discuss that separately.) And it also fits with SPARQL/Turtle/N-Triples where ':r' is treated as a kind of 'prefix with no name'. The closest we can get to that in XML mark-up is the default namespace prefix. The final thing about generating unique IDs (aka bnodes) we can look at a bit more--we might decide to add an algorithm, although my guess is that it's best not to. Regards, Mark As you can see, ':next' and 'next' can now diverge; the latter will *always* represent 'xh:next', since we've hard-coded the 'no prefix' rule. And ':next' may or may not represent 'xh:next', depending on the current in-scope default namespace. But note that this still removes the need for any preprocessing to find XHTML-specific values. Regards, Mark On 11/09/2007, Shane McCarron <shane@aptest.com> wrote: > I think the XHTML Working Group would disagree with your position, > Ivan. We have defined a bunch of reserved terms in the XHTML space, and > have declared that those map into RDF triples. I mean, I could be wrong > here.... but I don't think so. Further, we the RDFa in XHTML Task Force > have said time and again that extra triples are ok. Every instance of > @rel in a document is going to generate triples.... I can't see this > working any other way. > > On the other hand, I need to disagree with Mark for a different reason. > XHTML says that all non-qualified @rel / @rev values are in the XHTML > namespace. So I dont think we can change the CURIE rules to say that > they are instead in the default namespace - too error prone. I think it > would be fine to say a value of ':foo' is in the default namespace.... > assuming a grammar has a way to define a default. > > Ivan Herman wrote: > > Mark, > > > > I have given some thoughts but, after all, I decided to vote against > > your proposal. Sorry about that:-) > > > > The main issue I have is to avoid the generation of 'accidental' > > triples. The @rel attribute is not proper to RDFa and may and is used in > > other places in an XHTML file. The intention may _not_ be the generation > > of a triple but, in the scheme your propose, there is no way to avoid > > that. Eg, the <link> element use rel for a stylesheet; I am not sure it > > is relevant to generate a triple for the CSS file (certainly not without > > the user asking us to do it). > > > > Ie: a:b and :b are, in my view, the only two forms that we should accept... > > > > Ivan > > > > Mark Birbeck wrote: > > > >> Hello all, > >> > >> During the course of finishing off the Syntax document a couple of > >> issues have popped up. I'll deal with them in separate threads. > >> > >> This thread relates specifically to the way that we ensure that > >> mark-up like this yields the kind of triples we'd expect: > >> > >> <link rel="next" href="o" /> > >> > >> At the moment we say that some kind of preprocessor runs and that the > >> mark-up above is 'mapped' to this: > >> > >> <link rel="xh:next" href="o" /> > >> > >> This is fine, and if we're happy with that, we can just leave it. > >> However, there is another way to come at this, which I'll describe. > >> > >> Myself and Shane changed the CURIE definition recently so that *both* > >> the prefix and the colon were optional: > >> > >> [ [ prefix ] ':' ] reference > >> > >> This is so that all of the following are valid: > >> > >> a:b > >> :b > >> b > >> > >> We did this because the second format is needed in N3 and Turtle-based > >> languages such as SPARQL, whilst the third format is needed if we want > >> to be able to handle legacy QNames. > >> > >> I was therefore looking more closely at what exactly these three > >> different formats should mean since we don't have that defined clearly > >> in our specification. The most obvious route for the second format is > >> to say that it should use the current default namespace, making it > >> consistent with SPARQL, etc. > >> > >> However, there is no general practice for non-prefixed QNames--in some > >> situations the default namespace is used (such as in declarations of > >> type in XML Schema), and in some situations it is explicitly ignored > >> (such as when defining a template in XSLT). This means that we could > >> choose to use the default namespace, or define some other rule like > >> always using the XHTML namespace, or even the current value of [base]. > >> > >> An interesting thing comes about though, if we were to choose to use > >> the default namespace; returning to the syntax we had earlier: > >> > >> <link rel="next" href="o" /> > >> > >> we could obtain a predicate of 'xh:next' without having to do _any_ > >> preprocessing, but *only* if the default namespace was XHTML: > >> > >> <html xmlns="http://www.w3.org/1999/xhtml"> > >> <head> > >> <title>...</title> > >> <link rel="next" href="o" /> > >> </head> > >> ... > >> </html> > >> > >> I like this approach since I think it gives future authors a lot of > >> flexibility. It also, quite by accident, provides a way to remove the > >> need for a lot of the preprocessing we have been discussing. For > >> example, one could mark-up OpenID using a layout like this: > >> > >> <link rel="openid.server" xmlns="http://openid.net/" > >> href="https://api.screenname.aol.com/auth/openidServer" /> > >> > >> <link rel="openid.delegate" xmlns="http://openid.net/" > >> href="http://openid.aol.com/wezfurlong" /> > >> > >> Note that instead of worrying about trying to make "openid." into some > >> kind of prefix, we simply use the full string as the reference. > >> > >> Anyway, there you have it. The choices seem to be: > >> > >> * have a preprocessing step to get at 'legacy' properties and > >> short-forms, such > >> as xh:next. In this case we'd still need to say what unprefixed CURIEs mean, > >> but wherever we choose would make no difference to the preprocessing step; > >> they could be in the default namespace, the current document, or some explit > >> namespace; > >> > >> * or, we say that CURIEs with no prefix--with or without the > >> colon--use the default > >> namespace, and then leverage this to cope with some of the legacy properties > >> like 'xh:next' and 'openid:openid.delegate' _without_ the need for > >> a preprocesing > >> step. > >> > >> Myself, I can go either way; I'd prefer the second solution, since I > >> think it would be quite neat if we only used the preprocessing step > >> when it is really necessary. This is because although the > >> preprocessing seems pretty benign, we've never really discussed things > >> like the fact that the preprocessor must operate across all of the > >> attributes, in a consistent way. For example, the value of 'next' > >> would need mapping in both @rel and @about, for the following > >> statements to work: > >> > >> <html xmlns:skos="http://www.w3.org/2004/02/skos/core#"> > >> <head> > >> <link rel="next" href="o" /> > >> . > >> . > >> . > >> <div about="[next]" instanceof="skos:Concept"> > >> <span property="skos:prefLabel">Next</span> > >> <div property="skos:definitionl"> > >> Refers to the next document in a linear sequence of documents. User > >> agents may choose to preload the "next" document, to reduce the > >> perceived load time. > >> </div> > >> </div> > >> > >> However, if the CURIEs were using the default namespace you can see > >> that this mark-up would 'just work'. > >> > >> Your thoughts and votes please. :) > >> > >> Regards, > >> > >> Mark > >> > >> > > > > > > -- > Shane P. McCarron Phone: +1 763 786-8160 x120 > Managing Director Fax: +1 763 786-8180 > ApTest Minnesota Inet: shane@aptest.com > > > -- 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, 11 September 2007 15:51:11 UTC