- From: Shane McCarron <shane@aptest.com>
- Date: Tue, 11 Sep 2007 11:05:19 -0500
- To: Ivan Herman <ivan@w3.org>
- CC: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>, Ralph Swick <swick@w3.org>
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. 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 >> >> >> >> > > > -- 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 16:05:42 UTC