[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Design for Diverse Data

• From: "bryan rasmussen" <rasmussen.bryan@g...>
• To: "Dave Pawson" <davep@d...>
• Date: Fri, 25 Apr 2008 11:35:55 +0200

> >
> > Validate, send only one particular namespace to certain parts of the
> system.
> >
>
>  A transformation task? Not a validator?
>  NVDL despatches certain parts of an instance to a validator.
>  Not to a part of your system.

Well it basically serializes it in one form or another so that the
validator can understand it, if namespace x is validated by XSD and
namespace y by RNG it follows that it seperates them out in one way or
another, so basically this can be done by extracting out the data via
transformation and serializing anyway, of course I  have to write
non-declarative code to do this, NVDL gives simple declarative way of
handling all this work. Great. But it doesn't change the fact that it
seems in at least most cases if not all what NDVL would be doing is
basically the same as what I just described, albeit probably more
efficiently.

The use case for NVDL seems to be the oft used example of using two or
more namespaces together, from different organizations, probably each
organization has done the Schema definitions. In some cases the work
of making these two work together is not trivial therefore I would not
want to put the effort into doing it at the same time. Thus without
NVDL I would tend to separate them out and validate them separately.

However the use case becomes different if you are talking of a format
that is supposed to be extensible. Normally extensibility is
determined by having some construct defined in your schema that is
extensible, NVDL makes extensibility more easy to define in the way
you want it. That's fine.

But in the case where you are allowing in extensions in an advanced
way I prefer the XML Schema method, of knowing exactly where the
extension to your data occurs, and this is because the use of
extensions is determined largely by people sending things into your
system. I would want to have a secondary system to handle extensions
and clean the data for entering into the system so that I can be sure
the data that goes to different parts is not problematic. Normally
validation handles this, but in an extensible format that you don't
have a schema for an extension does not necessarily render the format
invalid, thus you can end up sending markup into your system that is
not considered in the design of the system etc. etc. so obviously you
preprocess. given the need to preprocess I would probably handle my
validation in the preprocess stages anyway, because in a large enough
system with a number of allowed extensions it might improve
performance to validate in a pipeline, ooh it validated step 1 to step
3 but not step 4 well that means I move it into Queue X for
casehandling.

In these kinds of situations which I spent more of my time in the last
few years I wouldn't want NVDL I would want XProc.

The example I gave earlier in the thread is one of my nightmares when
I consider XML handling in these kinds of systems:

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

I just think that NVDL introduces further manageability problems into
such a system without giving any benefit. This is different than the
effect of a technology such as Schematron or XProc they solve problems
in the system. What NVDL solves is an increase in my personal coding
productivity by allowing me to quite quickly in a declarative way
solve validation and extensibility problems in a format, but at the
price of introducing risk into the later part of the system unless I
process after the NVDL anyway, in which case if I'm going to process
after an NVDL before placing into the system I'm going to go with a
pipeline anyway, and then the productivity of NVDL is destroyed for
me. But I agree in a different kind of scenario NVDL would be a good
thing. I just think that the scenario where it will be good is
actually somewhat limited.

Cheers,
Bryan Rasmussenn

• References:
  • Re: XML Design for Diverse Data
    • From: "bryan rasmussen" <rasmussen.bryan@g...>
  • RE: XML Design for Diverse Data
    • From: "Cox, Bruce" <Bruce.Cox@U...>
  • Re: XML Design for Diverse Data
    • From: George Cristian Bina <george@o...>
  • Re: XML Design for Diverse Data
    • From: "bryan rasmussen" <rasmussen.bryan@g...>
  • Re: XML Design for Diverse Data
    • From: Dave Pawson <davep@d...>