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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: power uses of XML vs. simple uses of XML

[ Lists Home | Date Index | Thread Index ]
  • From: "W. E. Perry" <wperry@fiduciary.com>
  • To: KenNorth <KenNorth@email.msn.com>, xml-dev@xml.org
  • Date: Sun, 09 Jul 2000 16:21:32 -0400

I am sorry, but this illustration, which sounds so sensible, is in fact a
canard, and I feel obliged to take this opportunity to debunk it. The problem
lurks in the phrase 'multiple applications operating on a single document type'.
In non-trivial real-world applications that is hardly ever the case. My
application at my node performs a different process for a different purpose than
does your application at your node, even if my application may use your XML
document as one of its inputs. At the very least, my application uses your XML
document together with reference data (or application parameterization) which is
different from anything your application uses and is likely to be data unknown
to you. Bear in mind that the XML document which you send me is presumably the
*output* of your processing:  if you did not perform any operation to create
it--if you are simply passing along someone else's document--then you are
effectively not in the chain of process at all, and we should consider the
source from which you got the document as the input source for my application.
But if you did create from some process the XML document which you send me, the
schema for that document is, to you, essentially a static template for the
output of your application.

By contrast, what is important to me are the relationships between that document
(or, abstractly, that document's schema) and the other documents, or reference
data, with which I must combine your document in my application processing. That
is to say that I cannot usefully for my purposes validate your document against
the static schema which you might have used as the template for producing it.
Suppose that you are sending me notice of goods which you have sold, and I am
responsible for arranging the shipping. I can ship by any of five different
methods depending on the outcome of choices which are the essence of the
application processing that my node performs. What is important to me is not
that you have identified the customer in the proper form, but rather the results
of my lookup of a shipping address against that customer identification and then
my lookup of a shipping policy against the geography of that address. If your
identification of the customer--however valid it may be against its
schema--cannot yield me a usable address upon lookup, I cannot perform my task.

Because the salient business rules (in this case, for determining shipping
policy) are local to a processing node and the unique application which uses
them, there is no question of a 'uniform application of rules'. There is, in
fact, a unique application of rules, based not on the schema of your document
which I use as input, but on the relationships between data derivable from that
document and other data available to my application. The schema of those
relationships is local to and is, in fact, the essence of my application.
Regarded from the converse perspective, my application--and my application
alone--implements that schema. Identifying that schema of those relationships in
a static, abstract, or declarative form in no way raises 'above' the application
level the validation which I must perform against that schema.

In other words, the application logic--which specifies the task that must be
performed--determines the data, and the form of that data, required to carry out
the expected processing. That application logic requires however much code it
requires, and neither the form nor the quantity of that code will change simply
because some input to that process conforms to a static data model entirely
external to that process. When there is a change to some part of what the local
process does, there will need to be a new version of that process. On the other
hand, whether a change to the schema of an input document will require a change
to the application code at a given node is a question which can be answered only
at that node. Is the change to data which is used at all by that node? Even if
it is, does the new form of the data preclude its being reliably used by the
existing process at that node? These questions can be answered only at the
particular node, based on information local to that node which, by its nature,
the schema of a document which exists external to that node cannot know and
cannot express.

KenNorth wrote:

> > Schemas are only useful in some situations: many XML applications
> > built today already have data validation in them (in code).
>
> You've just pointed out an important reason to use schemas -- to minimize ad
> hoc validation by application code.
>
> Consider a scenario where you have multiple applications operating on a
> single document type. If there is a schema for that document, and all
> applications use the schema, there is uniform application of rules.
> Validation is consistent (at least for rules that are definable by a
> schema).
>
> On the other hand, if you do application-level validation, the logic must be
> duplicated across n programs. This presents a versioning problem. When there
> is a rule change, you must do n updates to source code, instead of updating
> a single schema.


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS