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 <[EMAIL PROTECTED]>
To: Shane McCarron <[EMAIL PROTECTED]>
CC: Ivan Herman <[EMAIL PROTECTED]>, W3C RDFa task force
<public-rdf-in-xhtml-tf@w3.org>
References:
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
