- From: Ken MacLeod <ken@bitsko.slc.ut.us>
- Date: 20 Apr 2001 10:42:49 -0500
- To: "RDF Interest" <www-rdf-interest@w3.org>
"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 UTC