W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > May 2007

Re: ISSUE: @href anywhere

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Thu, 24 May 2007 15:42:36 +0100
Message-ID: <640dd5060705240742y3fc5539axe00c1c5ae4560c44@mail.gmail.com>
To: RDFa <public-rdf-in-xhtml-tf@w3.org>

Hi Ivan,

> [...]

> I think the argument put forward in[2] for accepting @href on any
> element, too, is solely due to a forward expectation on what XHTML2 will
> do.

As it happens, it's not. :) It's based on the idea that if @href is
going to be an RDFa attribute, then the fact that it is not supported
everywhere in HTML is something that is HTML-specific. In other words,
just as @content and @property should appear everywhere, so too should
@href.

However, that's based on @href being an RDFa attribute...and one way
out of this is to say that @href is *not* an RDFa attribute. (Sorry
Shane.) Instead what we say is that @href is just an ordinary HTML
attribute (or a 'host language' attribute) but we are giving it some
RDF interpretation. Whether it is allowed 'anywhere' is then a
function of the host language, and not RDFa.

I actually like this approach because it is consistent; the current
situation of arguing over the minutiae of syntax on a case-by-case
basis is painful, because each time it happens we lose the notion of
RDFa being something generic, as we try to squeeze it into the very
specific HTML box.

I've therefore proposed that we slightly restructure RDFa to be:

  * a core set of attributes that are specific to RDFa, such as @about
and @resource;

  * a set of 'interpretations' or 'rules' that define how specific
languages like HTML can
    be interpreted as a collection of triples.

This is motivated in more detail here:

  <http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007May/0031.html>


> [...]

> If and when XHTML2 becomes a Rec (or Last Call, or Candidate Rec,
> I am not sure), we can think of a revised version of RDFa *adapted to
> XHTML2*. After all, XHTML2 can and will introduce other features that
> make sense in RDFa sense (<link> and <meta> everywhere!), so such
> extensions may become necessary in other areas of RDFa, too. Our goal at
> the moment is XHTML1.1/HTML5 after all.

In the model I'm proposing we'd achieve what you want by defining an
XHTML 2-specific 'interpretation' that explains how XHTML 2 constructs
'map' to RDFa. The core RDFa attributes would remain the same in all
languages, and the behaviour of @href, <link> and whatever else would
be defined in conjunction with the host language. If we don't do it
this way, then I don't see how we can make it work in the long term,
since 'versions' of RDFa are going to be difficult to support.


> A related, technical question: can I use *both* @resource and @href on,
> say, and <a>? Similarly, can I use *both* @resource and @src on and
> 'img'? My proposal is 'yes' and @resource has a higher 'priority', so to
> say, in terms of RDFa.

I think to keep the layers clean, two sets of triples should be
generated. :) I know I want my cake and eat it, so to speak, but the
point is that I'd like to define @href behaviour in a host language in
an independent way to the core attribute behaviour. To get priorities
they would need to 'know' about each other.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

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

  standards. innovation.
Received on Thursday, 24 May 2007 14:49:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:15:04 GMT