- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 11 Sep 2007 18:10:21 +0200
- To: Shane McCarron <shane@aptest.com>
- Cc: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>, Ralph Swick <swick@w3.org>
- Message-ID: <46E6BDED.7040208@w3.org>
Shane, thanks. It was indeed not clear. Shane McCarron wrote: > The XHTML Working Group is absolutely producing a separate document for > CURIEs. The reason we have incorporated the basic rules that apply to > XHTML+RDFa into the syntax document is so there is no dependency on this > separate document. When the separate REC is ready, we can editorially > update the syntax document. > Hm. My prediction is that the RDFa syntax document will become a REC _before_ the CURIE document will become a REC. In which case you cannot update the syntax document any more (unless issuing a new release...) I know, I am very 'selfish' here, and my primary goal is to have the current RDFa work done. Anything that smells a delay makes me feel itchy:-) Ivan > This has been discussed to death in the task force. I am sorry if it > was not clear. > > Ivan Herman wrote: >> This mail actually triggered a procedural issue for me, but maybe I >> misunderstood Mark's comment below. >> >> Is it the plan to produce a _separate_ document for CURIE-s? Mark's >> formulation below referring to "CURIE-s can be used in any language", >> etc, suggests that. >> >> I see a possible problem. >> >> Our goal is to have RDFa as a Rec. Ie, I presume, the RDFa syntax and, >> possibly, the RDFa primer will go through the usual channels to become a >> Rec, either by the SWD WG or the XHTML2 WG. >> >> If the CURIE becomes a separate document, that means we will have to get >> it through the REC channels, too. In view of its more general nature, >> that would mean that this document would have to be reviewed by, eg, the >> XML Core working group. This would create a significant delay, generate >> all kinds of discussions which, frankly, can go out of control. >> >> My proposal is to keep the CURIE issue to its strict minimum, keep it >> within the RDFa syntax document and, at least for now, *apply it to the >> RDFa case only*. Do _not_ make it more general than that for now. This >> could lead to a significant slow down of the RDFa REC which none of us >> want. >> >> Ivan >> >> -------- Original Message -------- >> Subject: Re: Fine-tuning CURIEs >> Date: Tue, 11 Sep 2007 16:50:48 +0100 >> From: Mark Birbeck <mark.birbeck@formsPlayer.com> >> To: Shane McCarron <shane@aptest.com> >> CC: Ivan Herman <ivan@w3.org>, W3C RDFa task force >> <public-rdf-in-xhtml-tf@w3.org> >> References: >> <a707f8300709110540wdf388d6ta2982fab00124295@mail.gmail.com> >> <46E6AE6C.2070407@w3.org> <46E6B2FC.9080901@aptest.com> >> >> 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 >>> >>> >>> >>> >> >> >> > -- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Tuesday, 11 September 2007 16:10:20 UTC