W3C home > Mailing lists > Public > public-grddl-wg@w3.org > November 2006

Re: issue-mt-ns : XML is not RDF

From: Danny Ayers <danny.ayers@gmail.com>
Date: Thu, 2 Nov 2006 21:44:11 +0100
Message-ID: <1f2ed5cd0611021244r7eedbf3ex8beecef786d68ed6@mail.gmail.com>
To: "Sean B. Palmer" <sean@miscoranda.com>
Cc: "Dan Connolly" <connolly@w3.org>, public-grddl-wg <public-grddl-wg@w3.org>, www-archive@w3.org
On 02/11/06, Sean B. Palmer <sean@miscoranda.com> wrote:
> > This may be ok, but as it stands steps outside the grddl-wg's remit
> > into TAG and (unchartered) RDF group's territory.
> Actually it doesn't. From a corollary of the definition of
> application/xml in RFC 3023, it can be demonstrated that someone
> publishing an RDF/XML document as application/xml is asserting the
> triples therein.
> The argument is that the following:
> [[[
>    An XML document labeled as text/xml or application/xml might contain
>    namespace declarations, stylesheet-linking processing instructions
>    (PIs), schema information, or other declarations that might be used
>    to suggest how the document is to be processed.  For example, a
>    document might have the XHTML namespace and a reference to a CSS
>    stylesheet.  Such a document might be handled by applications that
>    would use this information to dispatch the document for appropriate
>    processing.
> ]]] - Section 3, http://www.ietf.org/rfc/rfc3023.txt
> Means that it is appropriate for a user agent to interpret an RDF/XML
> document served as application/xml as RDF based on the namespace of
> the root element.

What about this:

<x:Something xmlns:x="http://example.org/things/"
    <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class />

Since such a behaviour is allowed, it follows that
> an author/publisher of such a document must expect the triples therein
> to be taken as asserted; therefore they are asserted.

I think you're probably right about it being allowed for a particular
consumer, I'm less convinced that it's reasonable for the author/publisher
to expect it. For example, take -

<smil xmlns="http://www.w3.org/2001/SMIL20/ <http://www.w3.org/1999/xhtml>"
    <body>Some text</body>

My agent may key off the existence of the RDF namespace declaration - that's
not forbidden by the RFC 3023 is it? So the publisher should have expected
it to be

> http://lists.w3.org/Archives/Public/public-grddl-comments/2006OctDec/0019
> > Content-Type: application/xml
> >
> > <html xmlns="http://www.w3.org/1999/xhtml "
> > [...]
> > 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.
> No, but this is an application/xml document. You must interpret it per
> the application/xml specification, which says that one may dispatch by
> following the namespace mechanism, whereby it is an XHTML document by
> root namespace dispatch.

As you state below, no such root namespace dispatch mechanism is defined.

It doesn't say that you may use random
> heuristics; therefore it cannot be an RDF/XML document.
> You can think of this as being an analogy to
> rdfms-qnames-cant-represent-all-uris. The RDF syntax can't model all
> possible RDF graphs. Likewise, neither can application/xml be the
> carrier type for all possible syntactically valid application/xml
> documents.

> Unlike with the former problem, however, there is a
> workaround: just use application/rdf+xml!

Well quite! The publisher of the namespace doc with application/xml has
decided not to - I wonder why?

It could be argued that root namespace dispatch isn't documented as
> being the primary mechanism for namespace dispatch,

Rather a strong argument, I'd say.

but it seems
> common sense given that the root element encapsulates the entire rest
> of the document;

It does, but I haven't surveyed the exceptions - I believe XSLT offers one.

moreover I would consider there to be overwhelming
> tool support for it, and consensus amongst specificationeers seems to
> be converging upon it.

It could be argued that the media type is totally irrelevant on the same
grounds (I wouldn't be particularly convinced of the alleged facts in either
case without a decent survey). In either case, it doesn't necessarily follow
that such an approach is a good idea, and certainly not without some
alternate specification on which to base interop.



Received on Thursday, 2 November 2006 20:44:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:09 UTC