Forwarded message 1
(I tried sending this originally in April and then again in June but
there was a problem with the system that the W3T hadn't fixed until
now. So here it is, at last; extremely late but hopefully not too
late.)
There was a recent thread about this issue [1] on www-tag which I can
clarify, and I have some further comments on the state of
namespaceDocument-8 in general.
According to Norm's nsDocuments draft finding [2], the TAG's plan for
dealing with namespaceDocument-8 is to document the RDDL model and
leave it to implementors to decide which specific approach to use
rather than mandating one of them.
I believe this resolution to be flawed, which I expressed [3] to Norm
on the #swig IRC channel via an analogy with robots.txt:
The power of robots.txt is that it was a standard approach and
it was easy, and since everybody used this one approach the
barrier for writing tools that grok it was very low.
Now, if you could go back in time and said "wait a minute,
instead of robots.txt we'll just publish a model and people can
decide how to implement that model on their sites", you'd end
up with several different approaches and as many implementations,
and the world would've dropped the whole idea of robots obeying
sites. I'm worried that a similar thing will happen with RDDL.
Norm replied that he'd "rather had one way to do it, but we don't",
and that RDDL 1.0 is actually quite widely implemented and that the
time to change it is likely passed.
I'm not so sure. I was around on xml-dev when RDDL was first proposed,
way back in 2001, and I've seen all the issues that have come up with
it since then. I saw how much joy there was at settling on a solution
after much turmoil, and then the subsequent aggrevation as people
wanted to move away from XLink and then move away from any
non-standard XHTML, and even to an RDF solution.
But now that we've been through that, we're able to produce a document
that details the RDDL model. Aren't we also, therefore, capable of
choosing one standardised way of doing things?
Misha wondered how GRDDL relates to RDDL, and there was great
confusion over the issue, with there even being the question of what a
GRDDL document is. A GRDDL document is, colloquially speaking, an
XHTML document using http://www.w3.org/2003/g/data-view as its profile
that hence allows itself to be transformed via some
link[@rel='transformation']/@href values into RDF/XML.
GRDDL is a way of squeezing authoritative RDF blood from the XHTML
stone. That RDF may be a kind of RDDL, or it may be other data, so the
GRDDL model does indeed subsume RDDL (as DanC wrote in [4]).
This means that some GRDDL documents can be RDDL documents too, which
is to say that they can be XHTML documents with the GRDDL profile
that, when transformed in the standard GRDDL way, result in RDF/XML
corresponding to the RDDL model. This is explained in nsDocuments [2],
but apparently not all that well.
I think that this approach, RDDL-in-GRDDL, should be considered as the
default approach to RDDL--but only if the provisions outlined in
section 3.3 of nsDocuments [2] are followed in such a way that there
is a single recommended RDDL-in-GRDDL transformation:
It's important to note that XSLT processing is not required to
take advantage of GRDDL. For well-known transformation URIs, an
application can be written to extract the data directly from the
source markup without actually running an XSLT transformation.
XSLT is only required when an application wants to support
arbitrary GRDDL transformations.
Norm told me about this [5] by saying that there could be two profile
URIs for GRDDL, one for GRDDL as it is now, and one for a
RDDL-in-GRDDL. That would certainly be a valid approach, but I don't
think it's necessary. The values of the transformation relations can
quite easily be used as globally unique identifiers. Although *GRDDL*
clients have to dereference them and apply the transformations, RDDL
clients (as noted in the nsDocuments quote above) can simply look at
the URI and know what to do. Moreover, they don't need to support all
of GRDDL, so they can be very specialised. RDDL clients would, in
effect, be subsets of GRDDL clients.
This approach seems, to me, to be all advantage and no disadvantage.
It's human readable and it's machine readable. It's authoritative, and
it results in the W3C recommended RDF/XML. It satisfies those who want
RDDL to be XHTML, and it satisfies those who want it to be RDF/XML. It
satisfies me and all of the other people who don't want RDDL to be a
non-standard version of XHTML--that's a significant extra validation
burden. It's a boon to the GRDDL cause of getting structured data
embedded in XHTML.
So what needs to be done? There are a few things:
* Norm says [6] that namespaceDocument-8 has stalled because he needs
to coordinate with Jonathan over the definitions of the RDDL nature
and purpose URIs. It is of course paramount that RDDL be stabilised in
meaning before proceeding with a RDDL-in-GRDDL solution if it is to be
recommended.
* The "well-known transformation URIs" alluded to in nsDocuments [2]
need to become reality. So would the transformations themselves and
the RDDL microformat that's to be used as input. But again, only one
transformation URI must become reality: the whole point of this
message is that I believe we need one approach, and one approach only.
But, therefore...
* First of all, we need agreement that this is indeed the case. I
think that the onus is on people now to describe either a) where there
is a disadvantage or disadvantages with the single standardised
RDDL-in-GRDDL approach, or b) where a proliferation of approaches
rather than one standard approach to RDDL will be architecturally more
beneficial than a single approach.
Norm, consider this your shot across the bows about talking to
Jonathan! But I think that the priority of that action may be at least
partially predicated on the outcome of any discussion surrounding this
message.
Thanks,
[1] http://lists.w3.org/Archives/Public/www-tag/2006Mar/thread#msg23
[2] http://www.w3.org/2001/tag/doc/nsDocuments/
[3] http://chatlogs.planetrdf.com/swig/2006-04-27.html#T18-27-47
[4] http://lists.w3.org/Archives/Public/www-tag/2006Mar/0026
[5] http://chatlogs.planetrdf.com/swig/2006-04-27.html#T18-34-16
[6] http://chatlogs.planetrdf.com/swig/2006-04-27.html#T18-26-28
--
Sean B. Palmer, http://inamidst.com/sbp/