- From: Shane McCarron <shane@aptest.com>
- Date: Tue, 11 Sep 2007 10:23:40 -0500
- To: Ivan Herman <ivan@w3.org>
- CC: Mark Birbeck <mark.birbeck@formsPlayer.com>, W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>
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
Received on Tuesday, 11 September 2007 15:24:03 UTC