W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2001

Re: RDF in XHTML

From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 20 Apr 2001 10:42:49 -0500
To: "RDF Interest" <www-rdf-interest@w3.org>
Message-ID: <m0vgnzmvba.fsf@bitsko.slc.ut.us>
"Jonathan Borden" <jborden@mediaone.net> writes:

> Ken MacLeod wrote:
> >
> > > Jonathan Borden wrote:
> >
> > > > What is wrong with the approach of including <rdf:RDF>
> > > > elements within XHTML defined by an XML Schema module for RDF?
> >
> > XML Schema can't, Eric van der Vlist spent a long time trying each
> > of DTDs, XML Schema, RELAX, and Schematron, and later TREX for
> > validating some of the "looser" but commonly expected modular
> > extensions to RSS.  *Just* RSS, which has constraints even further
> > than RDF alone.
> 
> I don't buy this. Are you saying that RDF has constraints not
> expressable by Schematron (for example)? Did Eric formally prove
> that XML Schema, RELAX and TREX are incapable of handling RDF or was
> it simply that he was unable to find a method of doing so?

Actually, it's that RDF (or RSS, in that case) does *not* have
certain specific constraints that is the problem.

Here's a quick tour of the major pieces of RSS grammar that will show
the issue:

<rdf:RDF 
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="http://purl.org/rss/1.0/"
>

  <channel rdf:about="http://www.xml.com/xml/news.rss">
    <title>XML.com</title>
    <link>http://xml.com/pub</link>
    <description>
      XML.com features a rich mix of information and services 
      for the XML community.
    </description>

    <items>
      <rdf:Seq>
        <rdf:li resource="http://xml.com/pub/2000/08/09/xslt/xslt.html" />
      </rdf:Seq>
    </items>

  </channel>
  
  <item rdf:about="http://xml.com/pub/2000/08/09/xslt/xslt.html">
    <title>Processing Inclusions with XSLT</title>
    <link>http://xml.com/pub/2000/08/09/xslt/xslt.html</link>
    <description>
     Processing document inclusions with general XML tools can be 
     problematic. This article proposes a way of preserving inclusion 
     information through SAX-based processing.
    </description>
  </item>

</rdf:RDF>

And some of the constraints:

  * in the <rdf::RDF> top-level element, there may be only one
    <rss:channel> and zero ore more <rss:item>, in any order.

  * in <rss:channel> and <rss:item>, they may have zero or one of
    <rss:title>, <rss:description> and <rss:link>, also in any order.

That's the easy part.

The hard part is that anybody can add extra elements almost anywhere
in those existing elements, as long as they are not in the RSS
namespace, and, within <rss:channel> and <rss:item>, as long as they
are only zero or one element (not zero or more).

With or without extensions, when validating you can only validate core
or extensions you have schema for, and you must accept merely
well-formed for the rest.

For RSS, RDF Schema validation works, naturally, but we were shooting
for a more "plain" XML schemata validation also since RSS places
constraints on its XML serialization beyond RDF.

[Any deeper look into RSS validation should probably go off-list.]

Now, coming up to RDF in general, it's questionable whether using any
"plain" XML validation is a desirable constraint.  A processor can
read in a set of triples from one source and write out an
RDF-equivalent set of triples that are not similar in XML structure to
the source whatsoever.

For "RDF in XHTML" specifically with relation to modularization of
XHTML, XHTML should have a way, via XML Schema (forget the DTDs), to
say "any well-formed XML here" and then say where "here" can be (like
in <head>).  (I think all good, extensible grammars should allow this,
but one spec at a time ;-)  This is what a lot of people think ANY
should mean, but we know that not to be the case.

  -- Ken
Received on Friday, 20 April 2001 11:42:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:49 GMT