[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Design for Diverse Data

• From: "bryan rasmussen" <rasmussen.bryan@g...>
• To: "George Cristian Bina" <george@o...>
• Date: Fri, 25 Apr 2008 09:00:27 +0200

I find the concept of NVDL useful because it makes declarative some
things that need to be done in every reasonably complicated validation
pipeline but not useful enough because it does not (from what I've
seen) allow any declarations that affect the state of the instance
after validation (maybe you can show if I'm wrong on this)

what I mean by the preceding, which admittedly sounds like something
one would not want to do, is something that I described in an earlier
email. In a context where I have an XML instance coming into the big
XML handling system programmed over a long period of time by many
different programmers in different languages with widely varying
levels of skills I want to preprocess the XML before it has actual
contact with the system. This is often done via validation, once we
have something validated it can go in.

NVDL is focused on allowing extensibility of the XML, but at the end
of an NVDL validation the XML instance is valid and unchanged. This is
of course a good thing in some circumstances, but in the context of a
large enough system that I don't trust I might want to do something
like:

Validate, send only one particular namespace to certain parts of the system.

Currently what I would do is to extract the relevant namespace and
serialize it via an XSL-T and send it to the part of the system that I
know can handle that namespace.

NVDL doesn't seem to help that.

Actually a declarative language that helps that is XProc, and I would
say that given the scenarios of what you can do with XProc and what
you can do with NVDL that what I would probably do is to just use
XProc, set up a pipeline for validation and so forth. It seems most
likely to meet needs of data processing applications. The use that I
see for NVDL, and I think the only real use I see for it when compare
it to XProc is to do validation of compound documents. (admittedly
NVDL will be more compact of a syntax than XProc but not significantly
more compact)

For these reasons I don't think NVDL will break beyond a very limited
subset of people using it.

Cheers,
Bryan Rasmussen

On Fri, Apr 25, 2008 at 1:27 AM, George Cristian Bina
<george@o...> wrote:
> Hi Bruce,
>
>  You make it sound like NVDL automatically allows anything everywhere in an
> uncontrollable manner. That is not true, you can get as many constraints as
> you put in the NVDL script and in the schemas it refers.
>  NVDL is not a mapping associating a namespace with a schema and each
> namespace appearing anywhere... It provides context dependent processing,
> you can combine content from multiple namespaces to create the document
> fragments that are then validated with a specific schema, you can perform
> multiple validations of the same fragment against multiple schemas, you can
> use different schema types for validation (XML Schema, Relax NG, Schematron)
> and more.
>
>  NVDL allows you to constrain the compound documents more that you will be
> able to do with any other schema technology. That's easy to demonstrate
> because one can write an NVDL script that creates a single fragment
> containing the whole document and pass that for validation to the specific
> schema.
>
>  NVDL is the successor of NRL. You can find some interesting use cases in
> the James Clark's NRL introduction:
>  http://www.thaiopensource.com/relaxng/nrl.html
>
>
>  Best Regards,
>  George
>  --
>  George Cristian Bina
>  http://www.oxygenxml.com
>
>  Cox, Bruce wrote:
>
> >
> >
> >
> > Even for compound documents, extension by the NVDL method seems even
> > scarier than the ANY element - at least you know where ANY is going to
> > show up.
> > In the context of developing a schema for the exchange of trademark
> > registration data among WIPO and states party to the Madrid Agreement,
> > OHIM put ANY in the base schema with the intention that it be replaced
> > by those additional elements required by each national office for their
> > internal processing not already provided for in the base set.  Other
> > offices would, in general, ignore those easily-identified elements.  As
> > elegant as NVDL appears to be, the unpredictability it introduces is not
> > just in machine processing, but in business processing as well.
> > Industrial property offices don't usually want to see data in a
> > submission that is not supported by some business rule.  Extraneous data
> > can create considerable confusion and potential liabilities.  Somewhere,
> > somehow, the overall business process has to be controlled in order to
> > reduce it to machine-based processing, that it, it has to be minimally
> > predictable, or the business won't invest in automating it.  It's fairly
> > easy to show customers how an XML schema makes their business objects
> > amenable to machine processing.  I don't think I'll be introducing NVDL
> > to them any time soon.
> >
> > We currently publish 10,000 patent documents each week based on a DTD
> > with an external table DTD and MathML and expect to introduce some
> > others.  So far, we haven't needed NVDL.
> >
> > Bruce B Cox
> > Manager, Standards Development Division
> > OCIO/SDMG
> > 571-272-9004
> >
> >
> > -----Original Message-----
> > From: bryan rasmussen [mailto:rasmussen.bryan@g...] Sent: Wednesday,
> April 23, 2008 11:57 AM
> > To: George Cristian Bina
> > Cc: Costello, Roger L.; xml-dev@l...
> > Subject: Re:  XML Design for Diverse Data
> >
> >
> > > NVDL is the solution once you have the problem of validating
> > > compound documents.
> > >
> > >
> > I agree when I think of compound documents as XHTML with MATHML and
> > SVG and RDF mixed, I find it problematic when thinking of exchanging
> > business data.
> >
> > Cheers,
> > Bryan Rasmussen
> >
> >
> >
> > _______________________________________________________________________
> >
> > 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@l...
> > subscribe: xml-dev-subscribe@l...
> > List archive: http://lists.xml.org/archives/xml-dev/
> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> >
> >
>

• Follow-Ups:
  • Re: XML Design for Diverse Data
    • From: Dave Pawson <davep@d...>

• References:
  • Re: XML Design for Diverse Data
    • From: "bryan rasmussen" <rasmussen.bryan@g...>
  • RE: XML Design for Diverse Data
    • From: "Cox, Bruce" <Bruce.Cox@U...>
  • Re: XML Design for Diverse Data
    • From: George Cristian Bina <george@o...>