- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 11 Sep 2007 17:56:12 +0200
- To: Mark Birbeck <mark.birbeck@formsPlayer.com>
- Cc: Shane McCarron <shane@aptest.com>, W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>
- Message-ID: <46E6BA9C.7040803@w3.org>
Mark Birbeck wrote: > Ivan/Shane, > [snip] > > <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>; I am sorry Mark, but that is the one I was objecting to. In my view this should not be a valid predicate for RDFa or, put it another way, such predicates should be ignored by RDFa > * 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> > As you say below, let us keep away from that... Ivan > 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 15:56:19 UTC