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

Hi Ben,

> I'm beginning to agree with Manu's argument here.

Manu's argument is that since we don't process Dublin Core @rel
values, why should we process HTML @rel values? The answer is that we
are dealing specifically with 'RDF in XHTML', and the HTML @rel values
are therefore part of the spec. Further, we only have an obligation to
handle DC values in @rel when there is the correct profile--if there
is no such @profile value then from the point of view of HTML, any
non-HTML values are just gobbledygook.

Now, that doesn't mean that we can't agree to ignore all non-prefixed
values, including HTML ones. All I'm saying is that the argument for
that would be that we can't find a better solution, and *not* that if
we ignore DC values we should also ignore HTML values.

However, as I've said below, I think there is a way through this.


> I could still be
> convinced otherwise, but there is a real value to keeping things simple.

There always is. That's probably the most used phrase on any W3C
mailing-list. :)


> Mark, I think one of the issues is that we cannot expect (nor should we
> attempt) to make RDFa the complete solution for parsing all triples in a
> page. If we leave the option open for rel="next" to generate a triple,
> but we don't specify that an RDFa parser *must* generate one in this
> case, then I think we just might be reaching the right balance.

Of course. That's one of the many solutions that we could adopt,
although it does blow wide open one of the major use-cases surely?
That of Creative Commons.

Anyway, I have looked at this a bit, and after getting very frustrated
with it, I decided to come at it from the other direction; what if we
didn't have a legacy problem? What if we were writing this from
scratch? How would we make use of the XHTML-vocab values in documents?

One possibility would be to define the default prefix mapping to point
to the XHTML-vocab, which would allow authors to write:

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

This means that we can still make use of the XHTML values--next, prev,
license, and so on--but authors wouldn't need to define a URI mapping
like "xh:" in order to do so.

Before anyone shouts about this, let me explain why I'm suggesting
this. Once you have an easy way to make use of the XHTML-vocab values,
then you could argue that from an _authoring_ perspective our job is
done; we have provided a convenient way to let authors use a list of
clearly defined values in their documents.

This has the effect of changing the @rel="next" problem into something
else--a 'legacy' question. And once it is a legacy question we can
apply different criteria to solving that. We could certainly say that
at this time we don't know how to deal with legacy values, and for now
these values are completely ignored. The good thing is though, that we
are not _ignoring_ the XHTML-vocab values; we're merely ignoring one
way that those values might be written.


> That way, we leave open the possibility of adding hGRDDL to process
> Dublin Core profiles, including a default profile for XHTML which
> processes non-namespaced items consistently, etc...

That's what I said before. :) But in addition, we can now say that
just as with @rel="next", DC is a legacy question, rather than a 'new
markup' question. To put it a different way, we have a way for DC to
be added to documents, and that is the normal RDFa syntax that uses
URI mappings. Authors are free to make use of that, so any use of
DC.creator with a @profile (for example) is clearly something that
goes into our _legacy_ processing bucket.

(Note that if it doesn't go into the legacy bucket, then we are
essentially saying that we support alternate syntaxes, which goes
against the spirit of RDFa.)


> In other words, this is a way for us to wrap up the spec *now*, keep
> things simple, and keep our options open for the future.

I think you are aiming at windmills here. :) I didn't suggest that we
add any processing rules *now*.


> To Manu's comment:
> > 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 are *absolutely* talking about RDFa in XHTML1.1. That's our scope,
> nothing else :)

Yes.


> Note one thing that may have slipped through the cracks, but that I need
> to bring back up as Creative Commons rep: a while ago, in the previous
> WG, we decided to add "license" as a reserved word for @rel. Whatever we
> decide to do with this, let's make sure not to forget that one.

Yes, "...vocab#license" should definitely be in there--I don't know
how it got dropped.

So, with your CC hat on Ben, how do you feel about this:

  This is licensed under a
  <a rel=":license" href="...">Creative Commons license</a>
  .

To summarise, what I'm saying is that we should tweak the primer and
syntax documents so that any usage of XHTML-vocab values have the
colon in front. We should send a clear message that *new* mark-up
should use this unambiguous method of specifying XHTML-vocab values.
Then we can leave the 'legacy question' for another day. :)

(Note that to make this work requires just a one-line change in the
syntax document, that sets the 'default mapping'.)

Regards,

Mark

-- 
  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 10:39:52 UTC