Lists Home |
Date Index |
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
>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
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