Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Two Questions - on XML Schema
 Michael Kay wrote: > It might be that we've reached the stage where we can't afford to do > things > properly so we have to do them cheaply. I thought we came to that stage ten years ago (i.e. XML)! Wrong audience on XML-DEV Michael :-) > If that's the case, then this i > probably the right way forward. However, one needs to be aware of its > limitations. For example, if there are two possible content models for an > element and you want to control which one to use based on an > attribute, then > you have to define the union of the two content models and design XPath > expressions that implement two permitted subsets. That seems pretty > unusable > to me. > > I don't think so. It means that the content models can become much looser, with the specifics of order and occurrence and co-occurrence dealt with by at the constraint level. From that POV, generalizing <all>'s cardinality is probably exactly the right direction for XSD. Recently I have been working with some people on constraint traceability: that all constraints implemented in a software system needs to be justifiable and traceable to a business requirement. The corollary is that good technologies for agile systems don't force extraneous constraints down your throat: you have to pay for these. In the case of schemas, for example, whenever a schema language forces you to specify an order for unordered data, this is a non-business -requirement-traceable constraint, which is a cost ultimately (or so the theory we are looking at goes...) XSD + Schematron fits well into this kind of mentality. Indeed, it is a conservative approach: RDBMS have schemas and constraints separate, UML has its constraint language separately. For this kind of approach, a sign of success for the basic structure language is that it allows modeling as *few* complex constraints as possible: broad picture, rough strokes, containment. Then the sign of success of the overlaid constraint language is how well and directly it can model or state business requirements on the simple superstructure. As a concrete example, think of schema evolution: having order and cardinality dealt with by a constraint layer rather than at the schema layer allows much more flxibility in variant schemas and versioning, exactly in the kinds of areas where complex type derivation is fragile; in other words, to an extent, the fragility and unsatisfactoriness of extension by suffixation and the limitations on derivation by restriction can be reduced by moving buasiness-rule-contingent constraints to a higher level. So I think Schematron (or a separate constraint layer) does more than just address tedious co-occurrence constraint requests, it can also allow type derivation to fit more comfortably by stuffing less into it. > To my mind, grammar-based constraints and value-based constraints > should be > much more closely integrated than this. And I don't think it's > impossible. > > I don't think its impossible, but I think its the wrong way to go. I think grammars should just be dropped in favour of paths entirely. It is silly to have one paradigm for schemas then have to use an entirely different one for data access. Of course, then you get problems with completeness detection, databinding, interface generation, etc. > That doesn't preclude the needs for generalized XPath-based > constraints in > the schema, of course. > > And it may well be that path constraints are ultimately best placed at some XQuery kind of level: multiple documents. Also, there is enormouse scope for debate on which kind of logic to use, for any new rule based system. (Schematron uses if..then logic, nothing fancy.) 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
|
|||||||||
