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

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/"
                     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#
">
    <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class />
</x:Something>

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>"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <body>Some text</body>
</html>

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


See
> 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?
>
> XHTML.
>
> > 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.

Cheers,
Danny.


-- 

http://dannyayers.com

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