RE: [xml-dev] When to Validate XML?

[Mike_Leditschke@nemmco.com.au]

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@bea.com>, xml-dev@lists.xml.org  
                    csoft.com>            cc:                                                                       
                                          Subject:     RE: [xml-dev] 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.