OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

> (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

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).


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>