[
Lists Home |
Date Index |
Thread Index
]
From: "Bob Foster" <bob@xmlbuddy.com>
> Since when are attributes order-constrained?
Oops: s/@value/text()/ but the point is the same. (I don't think attribute
orderr was the mistake: it is prop1 that provides the context.
<rule context="prop1[@value='ABC']" >
<assert test="following-sibling::*[1][self::prop2]">
When the value of "prop1" is ABC then "prop2" should follow "prop1"
</assert>
</rule>
<rule context="prop1[@value='XYZ']" >
<assert test="following-sibling::*[1][self::prop3]">"
When the value of "prop1" is XYZ then "prop3" should follow "prop1"
</assert>
</rule>
> What an interesting world-view! If you "squeeze" constraints into the form
> of a grammar you and others can visualize the structure of the document,
> i.e., the things that can be said. If you squeeze grammar into the form of
> constraints you just have a list of things that can't be said.
On the contrary, what you have is exactly a list of things that can be said:
you can format a Schematron schema as a list. The text of the assertions
is the basis for the implementing contexts and tests.
The kind of squeezing I am talking about is Jenni Tennison's (brilliant)
trick with trying to get value-structure selection in XSD. I cannot
remember the details, or even if it would work, but it was certainly
too tricky to expect anyone to use. Some people use the schema
to model what they need, and then the document format falls out
of that. Other people (quite legitimately) want to create a document
format so it is nice and idiomatic according to their eye; that is the
kind of person who does
<root>
<prop1 value="ABC">
<prop2 value="...">
</root>
rather than
<root>
<prop1>
<ABC>
<prop2 value="...">
</ABC>
</prop1>
</root>
Which is regular.
> Grammars are constructive. They can, and commonly are,
> used to generate user assistance to document authors, forms for data entry
> and readable documentation. Can't do that with assertions.
I don't see that.
You can do it with some grammars. You cannot do it with others,
such as grammars containing wildcards.
You can also do it with some (all?) assertions: all someone needs to do is to
make a library of the semantics of common idioms and some symbolic
processing. But you don't need some program to infer readable documentation
for Schematron: the assertions are already there in plain language.
If we did want to try to generate assertions, in a fit of madness,
lets say we have a pattern for <rule context="x"> where x is any
element name or or separated lists. We can now generate the head
of the assertion: "An element x should" or "Elements x, y, and z should",
Now for a rule like
<rule test="y">
we can generate " have an element y". And so on. It is just a matter of
translating the XPaths into natural language and in terms of constraints.
Similarly for drawing diagrams. You can make a star diagram with
the context node in the middle and rules hanging off them, for example.
Diagrams seem more useful for people who need to produce documentation
rather than for people who actually need to understand schemas IMHO.
The problem with assertions is not that you cannot extract anything from them,
but that people have not investigated this area. (In fact, I prototyped about
2 years ago a system for generating contextual author assistance from
patterns recognized in Schematon schemas, so it can work, but I am waiting
for more Schematron schemas to test whether it goes far enough. The main
problem is not that Schematron is assertion-based or XPath based, but that
it is typically open and typically is used to complement grammars--they are
typically open and sparse rather than closed and complete.)
I didn't say "don't use grammars for anything". But there is no reason why
an arbitrary database should have a dominant tree or natural tree; consequently
there every reason to expect that grammars are deficient for representing
the structural constraints of a database. Now we can add extra selectors
to as particles in grammars, but still we are stuck with regular structures
(what is the first child? what can follow it?, what can follow it? etc)
Which why I say "bite the bullet and introduce Schematron from early on".
> >There is a free drag-and-drop validator for XSD, RELAX NG and Schematron
> >for Windows at http://www.topologi.com/
>
> And very nice it is!
Thank you
Cheers
Rick Jelliffe
|
