Re: PROPOSAL: Extending @rel/@rev reserved value set

Hi Manu,

We have for a long time now been talking about the specifics of 'RDFa
in XHTML'. Whilst it is certainly the intention that RDFa should be
usable in any mark-up language, for a long time now we have narrowed
our goals to defining RDFa in the very specific context of XHTML. Once
this has been done, it should be quite straightforward to codify the
'general rules' of RDFa.

So, we are always dealing with a combination of the general rules that
come from RDFa, and the more specific rules that _could_ be derived
from the host language. I tried to come up with some terminology a
while back to help when we're discussing this, and you'll find the
first cut at this here [1].

Some of those in the latter category are quite straightforward, such
as using <link> and <meta>. But there were others, like using @class,
that although tempting, we stayed away from after deciding that we
would have been 'overloading' an HTML feature to mean more than was
intended.

At least with @rel/@rev--whether used on <link> or <a>--it is clear in
the HTML specification that a relationship between two documents is
being defined. (And of course, <meta> is just as clear.)

The following is a little long, because I've replied to each of your
points. But the executive summary is this:

Firstly, we are definitely dealing with 'RDF in XHTML', and have been
for a long time. This means that we have to be quite careful about
using HTML features and interpreting them as RDF, and also when we are
considering ignoring a language feature.

Secondly, HTML @rel values have a different status to values provided
by other taxonomies. So for example, when DC is present, a @profile
value should be set--that is required by the HTML 4 spec. This doesn't
mean we have to process those values now, but what it does mean is
that there is a long-term solution available.

And more importantly, what it also means is that any non-HTML values
can safely be ignored until the use of @profile is clearly
defined...perhaps in RDFa in XHTML version 1.1. :)

That leaves us with the problem of what to do with HTML's own values
in the current spec, but I'll save that for another post.

Thirdly, one of the things we need to solve is whether the rules we
are discussing apply to all attributes, or only to @rel and @rev. (You
suggest excluding them from the discussion, but that's the very
problem we are trying to solve.)


The remainder of this post is a set of clarifications on the above
points, and responses to some of yours:

>
> [snip]
>
> The way I see it, one of the issues is that of parser conformance.

Well...it's also about the 'use' of the language.


> Are we stating that any RDFa parser that doesn't do this pre-processing
> step in @rel and @rev is non-conformant? (I don't like this approach as
> it doesn't make sense for any non-XHTML document)
>
> OR
>
> Are we stating that in XHTML specifically, an RDFa+XHTML parser MUST
> perform the pre-processing step for @rel and @rev? (I'm fine with this)

As we've said for a long time now, it's the latter.


> In other words - it seems that in this instance, the host XML dialect
> has a great deal to do with defining what is and isn't conformant behavior.

Of course.


> > I suppose what it comes down to is that although you are quite right
> > that this is outside the scope of RDFa, it's not outside the scope of
> > _RDFa in XHTML_, which is, for the time being, what we are dealing
> > with.
>
> If we narrow the scope of this to be only about RDFa in XHTML, that
> would help things greatly. I just wasn't sure that we had narrowed the
> scope to that yet...

We did, many moons ago. :)


> > So we actually have three sets of 'legacy' values, in a way:
> >
> >  * those that come from HTML, which can be present without a profile;
>
> I'm fine with placing these in the "Required for a RDFa in XHTML parser"
> category. Those values, just to clarify, would be:
>
> alternate, stylesheet, start, next, prev, contents, index, glossary,
> copyright, chapter, section, subsection, appendix, help and bookmark
>
> is that correct?

Right. Although annoyingly "alternate" is a qualifier, so you have the
tricky problem of a space separated list of values, and one of the
possible values also has a space in it! But anyway, yes, that's the
list, give or take a few extra which might get in there if we agree to
move the values that are traditionally in meta/@name, into the same
collection.


> Should these go in the [default graph], or should these go in an [XHTML
> graph]? I would argue that they should go in the latter because they are
> outside of the core RDFa processing rules. They are extra processing
> rules that are a part of the RDFa in XHTML module.

You could do that, but it makes no difference to the problem we're
dealing with. Our problem is to define the *syntax* of values in @rel
and @rev, and where the generated triples are placed is secondary.

For example, we could say that any non-prefixed value in @rel/@rev is
simply ignored by RDFa. That doesn't mean we 'lose' the XHTML values
like @rel="next", because some pre-processor could come along and
simply convert this:

  <link rel="next" href="..." />

to this:

  <link rel="xh:next" href="..." />

Actually...it would probably be more precise to say this:

  <link rel="xhvocab:next" href="..." />

But anyway, the point is that although we might define the rule to be
'all non-prefixed values are ignored by an RDFa processor', the fact
that we know we are going to have a pre-processing step of _some_
description means that we can 'rescue' these important values, give
them a prefix, and then see them appear in our triple store.

Of course, this pre-processing step is not yet defined properly, and
that gives us an awkward problem, because we don't quite know for
certain how to phrase the RDFa itself in such a way that we know
things will work together.

That's the core of the discussion we're having, I think--which is not
to say that we need to define this pre-processing step before we can
proceed, but it does mean that we don't quite know what rule to come
up with to filter out values.


> Or are we stating that the [default graph] is actually the [default
> RDFa+XHTML graph].

I would say so, yes. But as I said, that's not at the heart of the
issue we're trying to resolve anyway, so it won't help us solve this.


> >  * those that come from other taxonomies (like DC) that will be accompanied
> >    by a @profile value;
> > ...in my mind the second category could usefully be placed into the
> > triple store too, since they have been clearly defined. In other
> > words, due to the presence of @profile they are not the 'spurious' --
> > or 'extra' ;) -- triples that everyone is so keen to avoid.
>
> While I sympathize with this argument, it is outside of the scope of
> XHTML, isn't it? RDFa+XHTML parsers are more than welcome to generate
> the triples themselves, but do we want to complicate the parsing rules
> by stating that the @profile MUST be read and triples generated for that
> profile?

You've lost me...what proposal are you talking about? No-one is adding
parsing rules. No-one said the @profile must be read.

My comments were directed at _your_ point saying that if we don't
process Dublin Core vocabularies, why should we worry about processing
HTML predicates? I was saying that (a) HTML values are actually
defined in the HTML spec, and (b) that I hope that we will _at some
point_ process DC values, too. I was saying that the key to both of
these is the presence or absence of a @profile value.

The 'how' of adding such rules will obviously wait until later.

(I then went on to 'anticipate' the argument that often comes up,
which is that we are not 'entitled' to process these kinds of values,
and I did so by pointing out that if a value is present for @profile
we are actually entitled to 'interpret' the values since HTML itself
allows this.)


> Another point I am attempting to make is that there is a cost to doing
> this - and that is added complexity. The biggest detractors of RDFa (and
> rightly so) argue that the W3C creates bloated specifications (SOAP
> being cited over and over again). I'm afraid that the more an
> RDFa-conformant parser has to do, the easier it will be for detractors
> to make the argument that RDFa is bloated. The part that would really
> sting is that they would be correct.

The W3C does generally produce bloated specifications, and if you've
seen HTML 5 you'll note that the trend is for even bigger
specifications. However, I've had the pleasure of working over the
last couple of years with Shane McCarron and Steven Pemberton on a
series of much smaller specifications, that provide more modular
components that can be used together.

So:

 * there are people who are actively trying to reduce the size of W3C
specfications,
   and increase modularity...it's difficult to get a spec that's
smaller than one attribute!
   (i.e., @role)

 * no-one is proposing any extra complexity anyway.


> >  * those that are of other types, like OpenID, and so on.
>
> Outside of the scope of RDFa and RDFa+XHTML, agreed.

But that is in a list of different types of 'legacy metadata'! That
was about clarifying the issue, not proposing that we process them.


> > I've been looking at this for a little while now, because I've been
> > wondering if in making this kind of thing possible, we may find a
> > solution to the broader question. (And of course, we may not. :))
>
> My fear is that in the name of "backwards compatibility", we are going
> to overly complicate the number of reserved values for @rel/@rev as well
> as the processing rules for RDFa+XHTML documents.

I don't know what you mean by 'complicating the number of reserved
values'. I think the _mechanism_ we adopt is the key thing here, not
the number of values; whether there are 10 or 20 reserved values
doesn't really make much difference. The question is to define what to
do with these damned legacy values. :)


> I realize that I was primarily the person that was pushing for
> orthogonality between @rel/@rev and @property. However, it is making the
> RDFa+XHTML processing rules and reserved values far too complicated.

I'm not sure where you are directing your fire here, especially since
there hasn't been a proposed change to the processing rules on this
subject for a while.


> Should we constrain the discussion to the following:
>
> - We are specifically talking about RDFa+XHTML parsers when discussing
>   backwards compatibility for @rel and @rev.
> - These rules do not apply to any other document other than XHTML/HTML.

See above.


> - We do not bring the legacy @rel/@rev reserved values forward to
>   @property and @instanceof.

That's one of the things that needs to be decided. You can't
'constrain the discussion' on the very issue that needs to be decided.
One way to look at this is whether the pre-processor should run on all
attributes or only on @rel and @rev.


> - Do we really want to start talking about another processing step for
>   anything with a @profile?

We've been talking about a processing step for a long time. It's a
catch-all bucket into which we can throw things that we don't quite
know how to deal with. That doesn't mean we have to define this
processing step--I certainly wasn't trying to.

Regards,

Mark

[1] <http://www.w3.org/2006/07/SWD/wiki/RDFa/ProposedStructure>

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Thursday, 18 October 2007 09:36:16 UTC