xml-dev - Re: Integrity in the Hands of the Client

[Paul Prescod <papresco@technologist.com>]

Joe Lapp wrote:
> 
> Once we do that, nothing prevents an administrator
> (or the client program he or she is using) from indicating that the
> author of a book is another book.  This DTD will not suffice.

...

> However, these link solutions all have one problem: nothing in the
> link specification allows a link element declaration to constrain
> the kind of resource to which a link links.  

...

Neither SGML nor XML DTDs are meant to, nor will ever be able to express
all interesting semantic constraints. SGML/XML cannot even express all
interesting *syntactic* constraints (try to make an attribute that
allows only valid DOS filenames). The question of what is the right
balance of simplicity and constraint expression is an interesting one,
and one that should be rethought from time to time. But the inability to
express a *particular* constraint is not evidence that the language is
fundamentally flawed. The only language that could express all
interesting contraints would be a Turing-complete one. 

I've toyed with the idea of a DSSSL subset (DSSSL-Check?) that would
return a list of error messages, or the empty list of the document was
conforming. The DTD would express simpler constraints and the
DSSSL-Check Spec would express the more complex ones. In a graphical
editor, the DTD constraints would probably checked in real-time and the
DSSSL-Check constraints would be checked periodically (since they could
conceivably be quite slow).

RDF may be a useful system in-between these two extremes. It is more
concerned with semantics (and probably less with syntax) than SGML, but
is not Turing complete.

> owever, in
> general, constraints between elements will be important.  For
> example, it would not be acceptable to store away an account
> deduction entry without having an associated account entry or to
> have an account entry that does not have at least one associated
> account-owner entry.  It seems to me that there are very few domains
> that can be represented without these kinds of constraints.

It is worth noting that SQL does not provide a complete system for
expressing all interesting constraints in relational databases. That's
why "business logic" often resides in proprietary stored procedures or
on completely separate application servers. 

>  The access
> language also needs to reflect the solution because in order for
> a server to implement constraints, all document update operations
> must be couched in the language of transactions.  That is, every
> document update operation must be associated with a transaction.

Please explain this point.

 Paul Prescod

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)