Lists Home |
Date Index |
- From: "Rick Jelliffe" <email@example.com>
- To: <firstname.lastname@example.org>
- Date: Fri, 7 May 1999 02:41:22 +1000
From: Roger L. Costello <email@example.com>
>I recall seeing a posting a few months back where someone posted a DTD
That was me! See http://www.ascc.net/xml/en/utf-8/resource_index.html
>for RDF. Upon reflection I find this puzzling. How could you possibly
>create a DTD for RDF?
Not at all. It was trivial to make a DTD for almost all of the RDF
I think the DTD is a lot clearer than their formal syntax. In fact,
syntax leaves out rdf:subject, rdf:object, rdf:predicate, rdf:type and
I have put these in today.
The only thing that eludes DTDs is the unlimited number of rdf:_n
I have put in 8 and you can add as many more as you need; they seem a
gratuitous carbuncle on RDF to me: I trust everyone will boycott that
form (the GratAbbCarb ?).
>It is my understanding that RDF documents can only be "well-formed".
>There is no such thing as a "valid" RDF document. Correct? /Roger
But for any particular group of documents you can make up a DTD for
And you can use a variant of the DTD to constrain your users to prevent
from using the rdf:_n attributes. That would be a prudent move. So in
you can have lots of DTDs which generate data that complies with RDF.
And you can generate a DTD (like mine) which should accept any RDF
document (providing, of course, that you include complete the DTD to
include any domain-specific element names: these can be included in the
>... By definition, the child elements in
>rdf:Description are arbitrary:
><!ELEMENT rdf:RDF (rdf:Description)*>
><!ELEMENT rdf:Description (???)*>
In order to think about the DTDs, we need to split the structure into
* The first is the direct structure (this is the DTD that I give)--it
says that an
rdf:RDF element has a declared content type of ANY--that is easy, and
it is what the RDF spec says, under all the fluff; Similarly,
can have a content model of ANY. It is important to realize that "ANY"
signifies this arbitrariness...
* The second is the "architectural" structure (I didn't give a DTD for
just put it in comments and a parameter entity; I could have used ISO's
Architectural Forms declarations to declare this architectural
this says that a child of an rdf:RDF must be
( rdf:Description | rdf:Bag | rdf:Set | rdf:Seq )
and gives the appropriate attributes for these. Because these are
elements, they do not have to be signified in the element type
you can use any name, as long as you have the correct attributes and the
content models). Rdf:Description would have an architectural content
(rdf:PropertyElement )* and the rdf:PropertyElement has its due
So conventional DTD modeling sees this as two structures, each of which
described using DTDs. Since the RDF people didn't use architectures,
forced to use BNF (which is incomplete w.r.t. XML, and incomplete and
confusing w.r.t. RDF) and are banished to cry for other forms of
The document can be validated against the direct DTD only, but the
indirect DTD, if constructed, could be used to valid using an
validator. (Probably that XAF tool could do it. You could also use XSL
to do this kind of validation: I have an article on the same site "Using
XSL for Structural Validation" which looks into it: of course, unless
XSL has some way to check for names generated from numbers, it
cannot validate all possible rdf:_n attributes, but that is a flaw in
At least the RDF stands as a notable application that doesn't use the
direct element type identifier to key the content model. Following
Makoto's excellent XTech99 talk about performing set operations on
content models, I have been a little afraid that other forms of
(e.g. architectural validation using attribute names, or content model
validations that follow IDREFs instead of subelements) have been
thrown out. Which is a shame, because parallel content models provide
some nice capabilities (as RDF may, in about a million years, prove).
I still find it difficult to see RDF as anything other than a way of
implicit relationships, which every DTD designer builds into their DTD,
explicit. This allows generic tools which understands the relationships.
But the generic tools still need to understand the schemas, so I think
does not take us very far in practise, apart from the drab tasks
of managing, navigating and visualizing. It is not a very thick layer,
so it is a pity they have such a restrictive syntax: the whole thing
have been an architecture that could have been retrofitted to any
DTD. A great opportunity missed, IMHO.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)