[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: property dependency checking
From: "Bob Foster" <bob@x...> > 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|