[
Lists Home |
Date Index |
Thread Index
]
From: "Jonathan Borden" <jonathan@openhealth.org>
> The DTD approach only works for carefully constructed OWL documents. I know
> this because any RDF document can be considered an OWL Full document and
> this was one of the prime reasons to invent OWL DL in the first place. I
> don't think it is possible to write a DTD that validates all legal RDF
> documents and invalidates all documents that are not legal RDF. It *is*
> possible to do this with RELAX NG, however, e.g. see
> http://www.openhealth.org/RDF/RDFSurfaceSyntax.html and
> http://www.openhealth.org/RDF/RDF1.rng
>
> You might use this as a good starting point for OWL (or use the RELAXNG
> developed for the 'new' RDF syntax).
Just to go further than my previous posting.
A standard which does not define itself using/providing/profiling a standard executable syntax
(e.g. schema) for its non-specific properties (i.e. its grammar not its semantics) should be rejected
on the QA basis of being error-prone. An unmeasurable standard is no standard at all, it is a sketch
for a standard or a parody of a standard. (Of course, there has to be the usual pragmatic exception
for bootstrapping: where there are no prior executable tools.) It is a fact of business that
vague contracts screw the weaker party.
Government and military standardization boards should seriously consider whether any
specifications which do not provide standard schemas can be considered to meet basic QA
requirements for loosely-coupled systems. From the QA POV, I suspect the combination of
"it doesn't matter if something has a schema or not as long as it is clearly described" and
"our schema language is W3C XML Schemas" completely miss the mark: I suspect the reverse
should be policy: it doesn't matter if the schema language is MS/W3C XML Schema, OASIS/ISO
RELAX NG or ISO Schematron, but it does matter that *some* appropriate and independently
designed and implemented executable schema language (which has itself been through some
kind of standards QA process) has been used.
Otherwise you have to catch syntactic problems by checks at the semantic level, which may
not be possible; better to catch semantic problems at the syntactical (schema) level as much
as possible.
The point being that making a DTD for XXX (or, better, a RELAX NG schema for XXX)
makes a profile of XXX which then meets suitable QA guidelines. That there may be XXX
documents that don't validate against that DTD or schema is XXX's problem for being slackly
defined in the first place (the fruit presumably poisoned by being on RDF's tree.)
Cheers
Rick Jelliffe
|
