[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: When to Validate XML?
I would agree with your categorisation and have expressed it in terms of "what", "where" and "when" in explaining it to others. In our project, the XML schema structure used largely optional elements, but did constrain the structure and basic content of the elements. So it answered the what and where questions. Application logic then checked for the presence of elements required by the business logic. This process was driven by the value of a mandatory field, and utilised application based validation rules. So the business people got to invent new processes without impacting the schema every time. Regards Michael Jeff Lowery <jlowery@sceni To: 'Subrahmanyam Allamaraju' <subbu@b...>, xml-dev@l... csoft.com> cc: Subject: RE: When to Validate XML? 08/11/2001 05:48 AM Subrahamanyam writes: > So, what schemas can capture are the constraints common to > all apps. How > about the following possibilities? > > (a) Each app (in the worst case) may use a slightly different > schema to > validate a given XML document. That is, each schema can capture any > special constraints local to the app. I see that this contradicts the > common notion that schemas are global. However, when it is > accepted that > each app can use its own logic to verify the data, why not extend the > same to schemas? Ugh. If the apps can agree on basic datatypes, how on earth are they going to process each other's data? However, wildcards and base types can be defined *in a common schema*. Certain apps may choose to extend such a schema by extending or restricting types in their own local schema. Existing applications operating of the base schema definitions can react passively to unknown derived type information. By this I mean that the existing apps can store extra data items introducted by unknown (to it) extended types (trusting the authoring app to do it's own local schema validation), or inserted in wildcard spots. If that's too 'loose' for the application's taste, then the base schema definitions can be finalized. > > (b) In the above example, each app has a slightly different set of > constrtaints for the same data. Can we not extend this > argument to say > that each app has its own view (both structure and constraints) for a > given document. In this case, each schema may specify only a > subset of > the structure/constraints. I see that the current validating parsers > won't tolerate this, but how does this sound in theory? I would say that 80% of the *stable* constraints can be defined declaratively in a schema language. This may represent a significant fraction of the total constraints of a system too, BTW (I have no numbers to back these claims up; I don't know that anybody does-- consensus?). The remaining constraints (content constraints as you say) I think vary at the rate business processes change; which is to say: not frequently, but often enough. Now, if data is fed unidirectionally from one process to another, the consuming process should be free to define its own content constraints. However, changing datatype constraints unsettles me. If would argue that datatypes represent invariable properties of objects, and if you're changing them (other than through type derivation), then you really don't understand the objects you're dealing with. In other words, objects own their properties, and a processing environment just chooses the ones their interested in (although they may assign new properties to the object; granted, the types of such properties could be changed by the assigning party, but I think those are a minority). So, datatypes = object properties (stable) content constraints = business rules (vary) I hope someone backs me up on this.... :-P > > Subbu > > > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://lists.xml.org/ob/adm.pl> > ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://lists.xml.org/ob/adm.pl> ------------------------------------------ This e-mail is confidential. If you are not the intended recipient, any use, disclosure or copying of this document is unauthorised and prohibited. If you have received this document in error, please delete the email and notify me by return email or by phoning the NEMMCO Helpdesk on 1300 300 295.
|
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
|