Resending with a different subject line, because I believe the problems
described at least should be acknowledged, even if the solution offered is
rejected.
Here's some advocacy for the "no" in today's [grddl-wg] poll :
To recap, the test case put forward by Dan involves an XML document [1]
which uses a namespace, and the corresponding namespace document [2] (only)
has a representation with all the characteristics of RDF/XML, except is
served with media type application/xml.
The question is how an agent which supports the GRDDL mechanism(s) should
interpret the namespace document - as RDF/XML, or a picture of RDF/XML?
One possibility is for it to treat it as RDF/XML (enabling it to derive the
statements necessary to extract RDF from the source XML document). It's been
suggested that the presence of a declaration of RDF/XML's namespace (and/or
a root rdf:RDF element) is an appropriate way of recognising the intent of
the publisher of the namespace document (and hence that of the source
document's publisher).
This may be ok, but as it stands steps outside the grddl-wg's remit into TAG
and (unchartered) RDF group's territory. The former is probably unavoidable,
but I also suspect it's liable to cause practical problems.
It does seem like a good idea for an agent to be able to interpret the ns
doc usefully, but it would probably be safest to try and reduce the
potential impact crater... I suggest treating namespace docs like Dan's
example as XML, but allowing the agent to use a specific named element as
the basis for interpretation. Might be a strawman, details below, the
problems first -
There's the general case of whether the presence of a namespace declaration
can define the document type, and whether this can override the authority of
the mime type. I could be wrong, but this seems counter-WebArch, and either
way likely to cause problems -
HTTP/1.1 200 OK
Content-Type: application/xml
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:rdf=" http://www.w3.org/1999/02/22-rdf-syntax-ns#">
// whatever
</html>
XHTML, RDF/XML or both?
Keying off the root element narrows things down considerably, but then
RDF/XML doesn't mandate a specific root element.
There's the more specific case of whether the GRDDL-capable agent should use
the RDF namespace. This narrows the scope, but this would still presumably
be a question for the owners of the RDF namespace.
So what I'd suggest is a rule as part of the GRDDL mechanism that on
encountering an XML element+attribute of the following form:
<dataview:namespaceTransformation
rdf:resource="http:/example.org/trnsfrm.xsl"/>
- in any XML namespace document (for which other rules don't apply), the
following statement should be asserted -
<> dataview:namespaceTransformation <http:/example.org/trnsfrm.xsl> .
So docs like Dan's example wouldn't be considered RDF/XML in their entirety,
just generic XML with a special-case element+attribute. (In practice it
would probably mean having something like grokXMLNS.xsl associated with the
data-view profile). The door would still be open for agents interpreting the
whole doc as RDF/XML, but (hopefully) their behaviour in terms of GRDDL
would be the same.
I think this would provide the desired functionality, with minimal raising
of issues elsewhere.
Cheers,
Danny.
[1] http://dev.w3.org/cvsweb/~checkout~/2005/grddl-ts/sq1.xml<http://dev.w3.org/cvsweb/%7Echeckout%7E/2005/grddl-ts/sq1.xml>
[2] http://dev.w3.org/cvsweb/~checkout~/2005/grddl-ts/sq1ns.xml<http://dev.w3.org/cvsweb/%7Echeckout%7E/2005/grddl-ts/sq1ns.xml>
--
http://dannyayers.com