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

Mark Birbeck wrote:
> I disagree that there is no issue here, and I'd certainly like for
> triples to be generated by the following mark-up:
> 
>   <link rel="next" href="..." />
>   <link rel="prev" href="..." />
> 
> Lots of nice things can be done with this data.

I'm sure there are! :) I believe I failed to mention my point, or didn't
construct the argument in a way that was useful.

The way I see it, one of the issues is that of parser conformance.

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)

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.

> 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...

> 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?

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.

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

>  * 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?

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.

>  * those that are of other types, like OpenID, and so on.

Outside of the scope of RDFa and RDFa+XHTML, agreed.

> 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 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.

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.
- We do not bring the legacy @rel/@rev reserved values forward to
  @property and @instanceof.
- Do we really want to start talking about another processing step for
  anything with a @profile?

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk Launches World's First Open Music Recommendation Service
http://blog.digitalbazaar.com/2007/09/09/bitmunk-music-recommendation/

Received on Friday, 12 October 2007 15:23:48 UTC