OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
"vocabulary constraints" and other constraints (was: Re: [xml-dev] RE: Difference between "normalize" and "canonicalize"?)

On 26 Feb 2009, at 11:19 , G. Ken Holman wrote:


 > I thought I was explicit when I said "all of the constraints for
 > XSLT as an XML vocabulary".  I wasn't saying "all of the constraints
 > for XSLT as an XSLT stylesheet".  And I added "as an XML vocabulary"
 > expressly to indicate I was not talking about stylesheet
 > constraints, only vocabulary constraints: the presence and absence
 > of elements and attributes.  I even gave an example of the kinds of
 > constraints I was speaking of.

 > Never would I expect any generic schema language to express the
 > constraints on the semantic interpretation of values found within
 > its elements and attributes.  That is the purview of the
 > applications interpreting the semantics of the instances. ...

 > Those are not the purview of generic applications tasked with simple
 > requirements (such as for editing XML documents) where the author is
 > guided in avoiding the improper creation of instances based on
 > explicit rules for the presence and absence of attributes.  Seems to
 > me to be a good role for schema constraints.

Hmm.  An interesting distinction here that you're attempting to
draw between the job of the editor and the job of the application.
I don't buy it, though.

Do you mean that if you had an emacs mode that could detect syntax
errors in your match patterns, or type errors in your XPath
expressions, without slowing you down and without getting in your way,
that you would turn it off, because it's not really within the purview
of an editor to know that much about constraints on specific values?
Do you turn off ID/IDREF checking in your editors, too?

Not me.  Every error the editor detects for me, before I try to
compile and run the stylesheet, is an error caught earlier in the
cycle and (usually) more easily fixed.  I don't believe in the
existence of the distinction you make between a vocabulary "as an XML
vocabulary" and as an application vocabulary (or whatever one might
call the other thing), except as a rough and ready distinction like
the one we conventionally make in programming languages between syntax
and semantics.  As Michael Kay has already pointed out, the key to
that distinction is: if we know how to specify it formally --
especially if we can specify it in a way that doesn't require a Turing
machine -- and check it automatically and conveniently, we tend to
call it (whatever it is) syntax.  If we don't know how, then it's

One of the great themes of computer science over the last sixty years
has been the long-running campaign to move more and more things out of
the "must be checked by eyeball" / semantics area, and into the "can
readily be checked by machine" / syntax area.

It was not so long ago, for example, that many experts in markup would
have said that if a vocabulary wanted to impose a rule that either
attribute A or attribute B must be present, but not both, then that
was an application convention or semantic matter, and was not part of
the syntax properly understood, since "the syntax" was what a DTD
checked, and DTDs didn't handle co-constraints.

If you believe that the boundary between what a schema language should
do and what it should not do is always clear, then it's no wonder you
confused people.  Particularly since pretty much every schema language
ever used with XML does more than constraining the presence or absence
of particular elements and attributes, so none of them sticks with
what you now seem to be saying is their only real business.

As I said when I was firing flak at you offline, we can't help having
our tools influence the way we think.  But it's dangerous not to be
aware of it and to confuse a distinction rooted in the contingent
properties of our current or recent toolset with a distinction rooted
in essentials.  Hence my friendly warning shot.

* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net

  C. M. Sperberg-McQueen

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS