Lists Home |
Date Index |
Damm and blast, forgot to copy to xml-dev.
Also, should we be using email@example.com (or at least
copying to) for this debate ?
---------- Forwarded message ----------
From: Fraser Goffin <firstname.lastname@example.org>
Date: 07-May-2006 22:06
Subject: Re: [xml-dev] Java NVDL implementation
To: "G. Ken Holman" <email@example.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 <firstname.lastname@example.org> wrote:
> At 2006-05-07 17:33 +0200, bryan rasmussen wrote:
> >On 5/7/06, Jirka Kosek <email@example.com> 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
> 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>