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

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

I much prefer this method that George discusses, basically extracting
the namespaces that you want into a new instance and serializing (I am
understanding that correctly right? It's generally what I prefer to do
as I find it 'safer'). I suppose though that there is a problem
involved in that if I bring in two namespaces, one with a document
element and one that extends the first, how do I serialize the
extending namespace. Obviously I need to write code to deal with each
instance (no problem doing this, just want to be certain we agree  -
and of course can always just drop non-understood namespaces)

I agree that theoretically Roger's observation that

"Thus, if a programmer writes code assuming the first (closed) content
model then his code is likely to fail.

The problem is with the programmer's misunderstanding of the content
model, not a problem with NVDL."

is sort of correct, instances in which it would not be correct would
be instances in which the content model was originally specified
without explicitly stating that one could extend every element node,
as is generally the case. It would require a really far thinking ERP
solution to have thought this out.

In such a case if someone added in NVDL( and did not use the method of
extracting via XSL-T) without knowing all the constituent parts of the
system that would be dealing with the XML would be up to handling
anything thrown at it, they might be inviting problems.

Furthermore while Roger would be correct in some instances that it
would be the programmer that made a mistake there is a significant
portion of the IT industry that seems of the opinion that programmers
make mistakes quite often and that tools and methods should be
designed with this in mind, and to protect them from accidentally
making mistakes when things are difficult to understand. I believe
that NVDL, which as I've said previously would be really useful for
Compound Documents, does not seem to help the programmers who need to
deal with XML data and process it for their big data silos and
whatnot. Rather the opposite I feel.

 As another example of the problems likely to occur in NVDL usage,
which do you think is the better fragment of XSL-T:

this
<xsl:template match="payment">
<tr><xsl:apply-templates/></tr>
</xsl:template>


as opposed to this

<xsl:template match="payment">
<tr><xsl:apply-templates select="paymentpart/currency |
paymentpart/amount"/></tr>
</xsl:template>


without extraction of the relevant namespace the validation which is
now very free but not extensible has affected the transformation which
is now very constricted and non-extensible, because obviously the
stylesheet writer should write stylesheets defensively or risk having
the business value of the Order presentation be ruined by the addition
of lots of other stuff creeping in (this example as all examples is
open to the conclusion of Roger that it is the programmers fault, or
to the conclusion that systems and tools must be kept up to date as
new extensions are allowed in[which I've seen in various projects can
be problematic to coordinate over a large enough set of business
partners]).

The point is that there is an intrinsic connection between the
predictability of the data format and the amount of leeway one can
allow oneself in programming up against it.

Now if one uses the method of extracting just the data we want to
process in a pipeline of our application I think in most application
scenarios we run into the question:

 why did you want me to use NVDL again?

 I use NVDL and then extract the data?? Why not just extract the data
and validate it with good old technology X?(with X probably standing
for XML Schema)

 I don't think the validation freedom is going to be enough of a sell
to those people, they tend to be conservative and not concerned with
freedom; what they want is not validation freedom or ease, what they
want is assurance that the data entered into their systems at all
parts are valid. I don't see NVDL providing any benefit there, as
opposed to technologies like Schematron which do provide this benefit.

There are other problems in the chain of things that happens in such a
validation of multiple namespaces that I don't have time to go into
here. Suffice to say that while I prefer the following procedure (only
for 'data' formats:)

Extract Namespace X, serialize -> Go to Validation for Namespace X
Schema -> Go to Validation for Namespace X Schematron -> other
validation etc.
-> processing of serialized Namespace X instance

I realize there are serious drawbacks for handling extensible formats
in this way as well.

Cheers,
Bryan Rasmussen









On Wed, Apr 23, 2008 at 1:48 PM, George Cristian Bina
<george@oxygenxml.com> wrote:
> Hi,
>
>  One should be able to obtain the document fragments that go to each
> validate action based on the NVDL script (the result of the dispatching part
> of NVDL).
>  An XSLT 2.0 implementation of NVDL that performs only the dispatching part,
> that is it extracts document fragments associated with each schema is
> available as part of oNVDL:
>  http://www.oxygenxml.com/onvdl.html
>  One can use the NVDL as a filter to get only the desired document fragment
> and pass that for further processing to the code that expects only that as
> input.
>
>  Best Regards,
>  George
>  --
>  George Cristian Bina
>  http://www.oxygenxml.com
>
>
>
>
>
>  Costello, Roger L. wrote:
>
> > Hi Bryan,
> >
> > Here's a summary of Bryan's message:
> >
> > Consider this XML:
> >
> >   <payment>
> >       <paymentpart>20</paymentpart>
> >       <paymentpart>45</paymentpart>
> >   </payment>
> >
> > A programmer may write code to sum each value in <payment>, e.g.
> >
> >   sum = 0
> >   loop through payment
> >      sum = sum + paymentpart
> >
> > With NVDL new elements may be introduced within <payment> and thus the
> > programmer's code may fail.
> >
> > Bryan, is that a fair summary?
> >
> > Here are some thoughts:
> >
> > NVDL changes this content model:
> >
> >   <payment>
> >       <paymentpart>20</paymentpart>
> >       <paymentpart>45</paymentpart>
> >   </payment>
> >
> > Into this content model:
> >
> >   <payment>
> >       -- zero or more other-ns elements --
> >       <paymentpart>20</paymentpart>
> >       -- zero or more other-ns elements --
> >       <paymentpart>45</paymentpart>
> >       -- zero or more other-ns elements --
> >   </payment>
> >
> > That is, it changes a closed content model into an open content model.
> >
> > Thus, if a programmer writes code assuming the first (closed) content
> > model then his code is likely to fail.
> >
> > The problem is with the programmer's misunderstanding of the content
> > model, not a problem with NVDL.
> >
> > What is exciting to me is that NVDL changes all schemas (XML Schema or
> > Relax NG) from a closed content model to an open content model, without
> > any changes to the schemas!.  To state it a bit dramatically:
> >
> >     NVDL unlocks closed schemas!
> >
> >
> > Comments?
> >
> > /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
> >
> >
>
>  _______________________________________________________________________
>
>  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
>
>