[
Lists Home |
Date Index |
Thread Index
]
Michael Champion wrote:
> >> Atom and ODF can't be used with most commercial XML tools.
> > Unless you use relax ng tools to convert to xsd?
>
>
>
> But Atom uses constraints that can't be expressed in XSD, so those
> people are going to be unhappy at some point, right? ... I'm
> wondering whether Atom (or one of the other specs that is normatively
> defined with RELAX NG) could do what they need to do with XSD+Schematron.
>
I see the new DOCBOOK (is it 1.5?) uses Schematron schemas embedded in
RELAX NG constraints.
I think they use Eddie Robertsson's XSLT script for embedded Schematron. See
http://www.xml.com/pub/a/2004/02/11/relaxtron.html?page=1
He has a similar script for embeddeding Schematron in XSD schemas. Its
disavantage for XSD is that it is not
type aware. But then neither are the XSD key and integrity constraints
currently. If you use a Schematron with
XSLT 2, then you can get type awareness.
>
> > I've always viewed Schematron as providing additional functionality
> > beyond what
> > my schema validation gives me, not as a replacement? Rick?
>
>
>
> <>I agree. I'm not sure whether to call a check against
> schematron-defined constraints "validation" or not, but it could be
> used to refine a "data contract" that had to be left open in XSD
> because of the lack of, for example, occurrence constraints.
If you define a schema language for XML as something which lets you
describe a tree with attributes, Schematron
is certainly a schema language and more.
If you define a schema language for XML as something which lets you
describe how the structures/relations found in an abstract
data set, considered as a graph of nodes and arcs or relations and
entities, have been concretely modeled using XML, then Schematron is
good as the only full schema language! There is no reason why an
arbirtary dataset should form a nice tree; indeed, the different ways of
marshalling/serializing databases to XML by different vendors and the
various discussions on the desirability of flatness/depths in XML
documents shows the weakness of regular grammars in this regard: the
act of choosing a
regular tree structure forces you to make decisions about which
structural links or relations are somehow "non-schematic".
If you define a schema language as something which lets you inply types
to information items, then schematron is
not a schema language (and possibly RELAX NG is not either!) When that
is your definition, then Schematron is
a constraint language.
Schematron will become more important as people get experience and as
business processes mature to instist on traceability
between business requirements and information structures. Grammars are
completely hopeless for this: they force
the schema to have extraneous contraints, they make it more easy to moit
the rationales for particular information items,
and they leave the developer muddled between expressing business
requirements and implementation decisions.
With Schematron, you can have a clean split between expressing business
requirements ("An applicant must
supply a driver's licence number") and the implementation ( <rule
context='applicant"><assert
test="string-length(license) > 7">...) . Using a grammar, this is
inverted: the business requirement becomes
an optional comment rather than the main deal; and extra constraints go
in due to the limited structural
possibilities (sequence, all, any, choice) rather than any actual
requirement: for example, the effective inability
of XSD to allow data dumps from databases to come in any order (RELAX NG
is better with "interleave";
XSD only includes my ANY content model).
"Traceability for alignment" is the next revolution; it is underlying
meme behind XML's success--people say XML is good
because text is debuggable and readable and hackable and
loose-couplable, but all these things are symptoms of the
greater undertow, which is to provide the traceability at all levels
that allows alignment from business requirements
to implementations. Ultimately, the requirement for tracability and
schema governance will allow grammar-based
schemas to fal back to their proper and limited roles: as slightly more
elaborate data dictionaries used to describe
implementation details that are not dealt with at a higher level by
rules languages. Thats how it looks to me
as at the start of 2006, at least.
Schematron supports alignment, grammars support disalignment.*
> <>
>
> > I haven't heard of anything merging Schematron with xsd validation.
I do not believe that XSD will ever get path constraints. It is
undesirable by all parties!
And it is unnecessary. XSD provides the <appinfo> element for embedding
extensions.
What should be of pleasant interest to vendors who like the idea of
adding path based integrity constraints to
types in XSD, is that ISO Schematron explicitly has a faility to allow
this kind of mix-and-match subsetting.
You want to just use the "assert" element but don't want to worry about
patterns or variables, then you
can just use that element (in the standard namespace).
See http://www.schematron.com/iso/P25.html#GEN38
We did this because we really wanted to make it as easy as possible for
vendors to add path-based constraints
in a standard way that would not involve them in any more testing or
difficulty than if they just went ahead
and added a single element of their own in the msot straightforward way.
In other words, the extra work that
a vendor needs to say "we support ISO Schematron's assert element"
instead of "we have our own path based
assertion element" is pretty well the typing involved in using the
standard namespace and names. Effectively
nothing.
Any vendor who is sick of having the same issues being constantly raised
internally and externally
and giving the weak answer "well, you could use Schematron if we
supported it" have a very quick
and easy way out. Just support ISO Schematron assert elements in xsd
appinfo elements. (Of course,
the full Schematron language gives much more at little cost, but the bar
to adding simple constraints
could not be lower. ) Personally, I have found that many of the
frustrations with the limitations and
baroqueness of XSD (or DTDs, or even RELAX NG) go away when simple
assertions are also
available.
Cheers
Rick Jelliffe
* Schematron (and any rule based languages which require natural
language statements for each rule) supports
alignment, grammars (and schema languages with syntax or structures that
add constraints not derivable from business requirements) support
disalignment. <>
|
