Re: Exact wording for non-prefixed CURIEs in @rel/@rev

Hi Manu/Shane,

I'll reply to you together because Shane's reply to Manu deals with
similar points.

On 22/01/2008, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
> Mark Birbeck wrote:
> > we don't have a problem with unprefixed
> > CURIEs in @about, @property, @datatype, or @resource.
>
> If we have a problem with unprefixed CURIEs in @rel and @rev, why are we
> not being consistent and stating that they don't belong in
> @about/@property/@datatype and @resource in XHTML+RDFa?

Well...first of all we are droping CURIEs that have no colon. That's
what I said in my last post, and even back in October.

But second, I don't believe it follows that because @rel/@rev has a
problem we should change everything.

For example, @about and @resource can take both URIs and CURIEs, so
what did we do? We devised the safe CURIE syntax:

  @about="http://example.org"

  @about="[dbr:Albert_Einstein]"

In my view @rel and @rev fall into the same category. They have legacy values:

  @rel="next"

and they have 'new' CURIE values, which could easily be expressed like
this, avoiding all ambiguity:

  @rel="[foaf:knows]"

That wouldn't stop us mapping the legacy values to CURIEs, etc.

But anyway, my point is that fine, we haven't gone that way, and
instead we've tried to make legacy @rel values 'look like' CURIEs, and
we've now hacked CURIEs to make it work. But let's not get too pleased
with ourselves, and start looking around for other stuff to chop up.
:) It's still a hack that we've done.


> > Anyway, I don't see why we'd want -- or need -- to remove ":blah". And
> > actually, thinking about it, we could change the mapping for the empty
> > prefix to be the current default mapping rather than XHTML-vocab,
> > which would fulfill my use-cases:
> >
> >   <div about="[:blah]" xmlns="http://xyz">
>
> This question is one of ignorance... I just don't know what the use case
> for this is... why should this be supported? You're going to ask why it
> shouldn't be supported, aren't you? :)
>
> I say it shouldn't be supported because it complicates the processing
> rules while not having a clear use case. Perhaps, there is one... but I
> can't see it. What's a real-world use case for this construct?

And I say give me the real world use-case for @rev. And the real world
use-case for @datatype. Or whatever.

Meaning simply that at some point can't we just say that stuff is in
the spec, because it's in the spec? Calling on me to justify every
comma and full-stop is laborious and time-consuming. We've have years
to raise these kinds of issues -- and you have even provided excellent
reviews of the document on a couple of occasions -- why choose this
moment to raise more stuff that will go round and round, and really is
not that big a deal?

...which sounds a bit harsher than it's meant to...but it's difficult
to find a way to write that. :)


> PS: I also second Shane's reservations that it would make supporting
> (copy/paste) into HTML 4 and 5 more difficult if we supported setting
> the default mapping using xmlns.

Yeh...and as I said to him too, I take it that means you want to rip
out namespaces altogether, since there is nothing specific to the
default prefix -- @xmlns:a suffers from exactly the same problem. :)

Anyway...like I said to Shane, it's not the end of the world whether
this is in our out, but it really does feel like a lot of fussing is
going on at the moment. :) I'd really like to finish what we have.

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 Tuesday, 22 January 2008 23:45:00 UTC