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


Help: OASIS Mailing Lists Help | MarkMail Help



   Fwd: [xml-dev] Java NVDL implementation

[ Lists Home | Date Index | Thread Index ]

Damm and blast, forgot to copy to xml-dev.

Also, should we be using jnvdl-help@lists.sourceforge.net (or at least
copying to) for this debate ?


---------- Forwarded message ----------
From: Fraser Goffin <goffinf@googlemail.com>
Date: 07-May-2006 22:06
Subject: Re: [xml-dev] Java NVDL implementation
To: "G. Ken Holman" <gkholman@cranesoftwrights.com>

>....  I'm looking only for a non-zero return code on any failure
>of validation of any bit, and a zero return code on successful
>validation of all bits.

Don't you want to know what the validation errors actually were ?

When we receive documents and validate them, if they fail we usually
send back a response to the caller (and to our logs) describing what
was wrong (e.g. SOAP Fault details) ?


On 07/05/06, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
> At 2006-05-07 17:33 +0200, bryan rasmussen wrote:
> >On 5/7/06, Jirka Kosek <jirka@kosek.cz> wrote:
> >>My understanding of NVDL is that its main purpose is validation and
> >>JNVDL thus implements standard Java API for invoking validation. So when
> >>your document is valid, there is no return. If there are some errors (be
> >>it validation problem on NVDL level, or validation errors against
> >>particular schema referenced from NVDL) you get these errors (as
> >>exceptions, or you can register your own ErrorHandler to handle them on
> >>your own).
> >>...
> >
> >My understanding of NVDL is in agreement with yours.
> And mine.  I'm looking only for a non-zero return code on any failure
> of validation of any bit, and a zero return code on successful
> validation of all bits.
> >But I think most
> >developers would want the validation process to lead to an output of
> >the seperated xml,
> I disagree ... that is not something that I anticipated would need to
> happen in a development environment ... I'd be using XSLT and my
> match patterns would effectively dispatch the input stream to the
> various handlers.
> I do agree it is something needed for a training environment, and I'm
> planning to address that for my NVDL training with some custom code.
> >this could be used, for example, as the first step
> >in a pipeline so that:
> >
> >NVDLValid -> handleValidSeperatedXML
> >
> >NVDLInvalid -> handleNonValidSeperatedXML
> >
> >otherwise I think, that for most applications likely to be
> >encountered, the NVDL validation is useless because after NVDL
> >validation they will have to (or want to [not the same thing, but most
> >people act as if it were]) do the same thing they would have to do
> >without NVDL validation, namely seperate out the namespaces.
> But I would have anticipated that separating out the namespaces would
> not be helpful because it would lose context.  Certainly in my XSLT
> stylesheet acting on an instance of multiple namespaces I would
> absolutely need to know context and act on a particular subtree based
> on the parent of the apex.  And, as well, even if there was no
> relationship to the parent, in XSLT the entire tree would be
> available to my calculations and transform as I acted on the presence
> of multiple namespaces.
> >And if they seperate out the namespaces correctly than it is not a big
> >thing to validate the seperated XML, if they seperate them incorrectly
> >(really, there are developers I would not trust to do this) well then
> >it would be nice if their validation took place after seperation.
> Fine, but then it is just an exercise in XSLT or Python/SAX to create
> individual instances out of context and pass each one through
> validation and act on them.
> >At any rate if the developer has to seperate the namespaces themselves
> >I am sure they are going to want to validate the document after
> >seperation.
> Fine, but then I don't think NVDL is the tool they need ... NVDL will
> validate the use of namespaces *in the context* of the document
> without disturbing that context and making the entire document
> available for processing as a whole.
> Remember that XSLT acts on XPath addresses without validation ... so
> if a stylesheet knows that a document is valid, it can skip its own
> validation and just act on the information items ... and if a
> document is not considered valid structurally before being sent to
> XSLT then there is no assurance the XSLT will work properly.
> >And if they are doing that, why not do just that and skip NVDL?
> If they don't need the separate namespaces in context, then I totally
> agree: skip NVDL as it doesn't apply.
> >The use case for NVDL without some way to hook into the seperated
> >streams will seem very small to the average developer, I think.
> I disagree.  I think the developer will more than likely be working
> on the whole rather than on the separate bits, otherwise they would
> have to invent their own ways of maintaining context on the separate
> bits to make the processing of them meaningful.
> Whereas they can act on the whole in a single process with the
> NVDL-based assurance that the whole mixture of namespaces is as
> expected according to the NVDL script.
> I hope this helps.
> . . . . . . . . . . Ken
> --
> Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
> Also for XSLT/XSL-FO training:    Minneapolis, MN 2006-07-31/08-04
> Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25
> Also for XSLT/XSL-FO training:    Copenhagen,Denmark 2006-05-08/11
> World-wide on-site corporate, govt. & user group XML/XSL training.
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
> Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
> Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/x/bc
> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
> -----------------------------------------------------------------
> 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://www.oasis-open.org/mlmanage/index.php>


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

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