- From: Shane McCarron <shane@aptest.com>
- Date: Tue, 11 Dec 2007 14:29:08 -0600
- To: Ben Adida <ben@adida.net>
- CC: public-rdf-in-xhtml-tf@w3.org
- Message-ID: <475EF314.5050607@aptest.com>
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 UTC