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

Re: @profile is wrong solution for indicating that RDFa is present

From: Shane McCarron <shane@aptest.com>
Date: Tue, 11 Dec 2007 14:29:08 -0600
Message-ID: <475EF314.5050607@aptest.com>
To: Ben Adida <ben@adida.net>
CC: public-rdf-in-xhtml-tf@w3.org
I completely agree that we have enough work on our plate.  However, I DO 
NOT believe the group has agreed on a portable, universal announcement 
mechanism.  Mark's mail has brought that issue into sharp relief for me.

Mark's point (forgive me for jumping in here) is that @profile IS NOT 
the "GRDDL way" for announcing transformation rules in XML languages, 
and we have defined an XML language.  In the GRDDL spec it defines a 
mechanism for XHTML announcement of transforms [1], and honestly - we 
need to use that.  There is another mechanism for generic XML... we 
could use that too (@grddl:transformation) if we incorporated the GRDDL 
attributes into our spec.  However, I don't see that as a real option 
that the GRDDL community would embrace.  Regardless, we have to use one 
other the other.  Of course, I also don't think we need to mandate that 
people include GRDDL transform connections in their RDFa documents.  You 
only need that if you want to use GRDDL, right?

We have also defined a place holder location for an @profile value, and 
I think that we *could* use that @profile value for announcement that a 
document is a candidate for RDFa triple generation.  We can certainly 
even require this in XHTML+RDFa conforming documents.  These documents 
MUST use our DOCTYPE and MUST be valid, so authors clearly MUST already 
have complete control over the document.  Finally, we *could* populate 
the document at the end of the @profile URI with the requisite markup so 
a GRDDL processor could automatically find a transformation tool.  This 
would help is going forward, although it is not really a requirement today.

Looking beyond XHTML+RDFa...  we do have a REQUIREMENT that an author 
not have to change the head in order to have their embedded content 
interpreted as RDFa. So, as we get into the wild with RDFa we cannot 
REQUIRE that the profile value be set, nor that the DOCTYPE be changed, 
nor anything else in the head, really.

Having said this.... I don't honestly believe we need a mandatory 
announcement mechanism.  A conforming RDFa Processor could be 
*permitted* to ONLY process documents that use our defined mechanism 
(@profile value?  DOCTYPE?), but such a processor MUST NOT be precluded 
from processing any document it wants.  After all, every XHTML document 
in existence right now could generate triples with no modification 
whatsoever (see my example below).

So my proposal is that we change section 4.3. RDFa Processor Conformance 
by adding an additional conformance requirement (probably first):

    A conforming RDFa Processor MUST process documents that adhere to
    the rules defined in Section 4.1.  A conforming RDFa Processor MAY
    also process documents that do not adhere to those rules. 
    Regardless, all such processing MUST be done using the processing
    model as defined in section 5.

Example XHTML 1.1 document::

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
                      "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
   <head>
      <title>An example</title>
      <link rel="next" href="http://www.example.org/nextChapter.html" />
      <link rel="prev" href="http://www.example.org/prevChapter.html" />
   </head>
   <body>
      <p>Some content</p>
   </body>
</html>

I think this document generates triples for next and prev relative to 
itself (the implied @about) - doesn't it?  Although I can't seem to find 
an implementation that works this way......

[1]  http://www.w3.org/TR/2007/REC-grddl-20070911/#grddl-xhtml


Ben Adida wrote:
> Mark,
>
> I should have responded more quickly, but I've been swamped in other work.
>
> This issue has been discussed, and a solution has been selected, which
> the task force officially approved. I don't think that a complication of
> enough significance has been found to reopen the issue at this point. So
> let's not.
>
> We've got enough work to finish up already!
>
> -Ben
>   

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Tuesday, 11 December 2007 20:29:31 GMT

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