Re: [xml-dev] XML Design for Diverse Data

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

Hi Roger,

I was actually a very determined opponent of NVDL until recently when,
one day pacing around my office, I realized that there was a use for
it. I agree it is good for validation of Compound documents, in the
understanding of the Compound Document Formats group but definitely
not for passing around data between systems, with the understanding
that systems are probably big ERP systems with lots of programmers on
them and complicated  workflow etc.

Why the first and not in the second one?

Well, NVDL as I understand it (and this understanding was formed more
than a year ago so perhaps it has changed since but I doubt it) does
validation of the instance data and then leaves the various namespaces
in the same instance. This is useful for a compound document in which
the the various formats must interact in an a behavioral manner, such
as creating a presentation of the data they represent. But if the
format that is being transmitted is what is generally understood as
data in nature, for example business data, NVDL encourages extension
mechanisms that in my experience most ERP systems can not
pragmatically be redesigned to handle, for example if I have a system
that is supposed to handle the format Order in the Order namespace, if
I later want to extend that format I can do so by specifying in the
XML Schema way: extensions happen under the element with the name
Extension, or I can specify that extensions are done in the NVDL way
which is basically putting the extending markup wherever I want. I
might prefer to do things the NVDL way but in this context I am
talking about big systems with code in multiple places developed by
many different people.

In such a system people have probably made all sorts of assumptions
about the data, perhaps because they have only seen examples of Order
or read the Order schema, so that when one gets down to the part of
Order that has the following structure according to the schema (the
following obviously a bad example of business data as no exchange rate
is defined etc. ):

<payment>
<paymentpart><currency>DKK</currency><amount>2700</amount></paymentpart>
<paymentpart><currency>USD</currency><amount>120</amount></paymentpart>
</payment>

some programmers have done the following in some out of the way part
of the system:

when element = payment
loop child nodes - addamount(node1,node2)
end loop

so when we send in new extended data

<payment>
<paymentpart><currency>DKK</currency><amount>2700</amount></paymentpart>
<paymentpart><currency>USD</currency><amount>120</amount></paymentpart>
<ex:paymentoccurrence><ex:paymentqualifier>SEK</ex:paymentqualifier><ex:time>2200</ex:time><ex:date>some
date</ex:date></ex:paymentoccurence>
</payment>

The bugs introduced in such a scenario into these kinds of systems
are, I think, somewhat harder to detect than bugs introduced in a
browser.

For this reason when it is business data that I am expecting to work
in a bunch of systems over which I have no control and which has
probably been developed by many different people I would prefer to
have something more limiting in the structure allowed in to the
internal processes of the system, even though personally, in my own
life, I might prefer to have a freer and more extensible structure to
the data I am working with. This paragraph is in fact a true
representation of my feeling on the matter, so there's no need to
explain to me how I need to learn to appreciate extensibility, I do
appreciate it. I've just also seen some things that teach me that not
everyone are set up to handle it.

Cheers,
Bryan Rasmussen


On Tue, Apr 22, 2008 at 10:23 PM, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
>  This NVDL stuff has opened up new worlds in XML design for me.
>
>  I've written a short article describing various ways to design an XML
>  instance document that is to contain diverse data:
>
>  http://www.xfront.com/xml/design/compound-documents/index.html
>
>  Comments welcome.
>
>  /Roger
>
>  _______________________________________________________________________
>
>  XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>  to support XML implementation and development. To minimize
>  spam in the archives, you must subscribe before posting.
>
>  [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>  Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>  subscribe: xml-dev-subscribe@lists.xml.org
>  List archive: http://lists.xml.org/archives/xml-dev/
>  List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>