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

I think that I think of extra namespaces extending a canonical format
in this context, and as such I want to have the canonical format
seperated and purified from its extensions when sent to an
application, or maybe I'm having something of a problem seperating
what I want from what other people tell me they want (here I am
thinking especially in the context of UBL)
> 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.
>
I think there is just as little chance of the xslt working properly in
this scenario as in mine.

I'm envisioning a situation where:

1. I write an xslt for documents in namespace x.
2. someone wants to extend documents in namespace x with namespace y.
3. They write an NVDL to validate these two namespaces.

Thus the document then still get passed to my xslt, or should the xslt
be updated? I think it should probably be updated because now the
structure that is coming is no longer that which was originally
expected. Hopefully of course I have structured my xslt well, in a non
dependent template manner so that the two namespaces are effectually
seperated, but that cannot be certain. Another thing that cannot be
certain is what I have done with text nodes, I tend to use the default
handlin
g for text nodes, if namespace y has text nodes suddenly what is
coming out on the other end might not be as good as it was before.

I think this way is to interconnected and harder to maintain than the following

1. I write an xslt for documents in namespace x
2. someone wants to extend documents in namespace x with namespace y
3. they write an nvdl to validate these two namespaces
4. NVDL valid stream for Namespace x will be passed to my xslt
5. someone writes perl script for namespace y to save NVDL valid
stream to filesystem.

or other similar scenarios which returning the streams would allow for.

Cheers,
Bryan Rasmussen

> >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@C...
> 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>
>
>