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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: RELAX to ISO

[ Lists Home | Date Index | Thread Index ]
  • From: Rick JELLIFFE <ricko@geotempo.com>
  • To: xml-dev@lists.xml.org
  • Date: Fri, 27 Oct 2000 14:52:55 +0800

rohit srivastava wrote:
> 
> Rick,
> 
> Do you think that the co-occurence constraints that schematron offers, will
> find their way into Schema? I found the co-occurence constraints that
> Schematron offeres, to be extremely useful, and it would be nice if the w3c
> adopted them in their Schema recommendation(when they release it).

No, I do not expect it, nor would I welcome standardization of
Schematron as part of XML Schemas. I do expect that when people see that
the needs of human-readable markup languages are different from
serialized databases there will be more support for approaches like
schematron.  It is easy to confuse people into a too-extreme approach
(i.e. W3C Schemas=bad, RELAX=good) rather than a reasoned analysis based
on "how practical is this for my particular situation?"

The schematron approach is based on starting from an Xpath, not from an
element. 
I tend to think that the "type" abstraction is specious for document
interchange: one needs an enormous infrastructure to express simple
relationships. If one was making DTDs with 1,000 elements regularly (or
even with 100+ elements) there would be more point.  But small schemas
are more common than large ones, and the mangability is different: the
needs that large enterprises have are different from the SME developer
who just wants to send a little data from A to B.  

So there are no hooks in W3C XML Schema's internals for things not based
on elements or attributes or data.  Furthermore, XML Schemas does not
have a 1-1 relationship between element and type: this can complicate
creating path-based rules, until XPath gets type as an axis or until DOM
gets the ability to hold the Post-Schema-Validation infoset items.

(By the way, I hope people realise that the full power of W3C XML
Schemas will not be available for perhaps a year after it is released:
validators and non-standard PSVI APIs will be available fast, but a
standard way to access the PSVI infoset would be in DOM 4 or DOM 5, I
would expect!   Perhaps some of the trivial things such as value
defaulting might be available by overwriting the DOM.   So when you
weigh up the complexity/power benefits of XML Schemas, you might do so
with an eye on the mid-term: in the short term is it proprietary systems
all the way.  Or so it seems to me.)

So the appropriate place to put a Schematron schema in an XML Schema is
in the <annotation><appinfo> of the very top level.  I don't see much to
be gained by putting it in appinfos of individual elements.  I certainly
designed schematron so that it could be fitted in at that kind of
position, and it would be useful there, especially for expressing the
(somewhat artificial) category of "business rules".

However, there might be a nice language that could be made to fit into
the appinfos: a sort of half-assed schematron.  It could be very
useful.  Anyone considering such an approach should consider using Lee
Bucks's  Schema Adjunct Framework (see the Extensibility website, I
think), which is created to help that kind of thing.

Rick Jelliffe




 

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

Copyright 2001 XML.org. This site is hosted by OASIS