RE: [xml-dev] XML Design for Diverse Data

["Cox, Bruce" <Bruce.Cox@USPTO.GOV>]

Thanks for the correction, George.  It appears I had it turned
completely upside down.

Bruce B Cox
Manager, Standards Development Division
OCIO/SDMG
571-272-9004

-----Original Message-----
From: George Cristian Bina [mailto:george@oxygenxml.com] 
Sent: Thursday, April 24, 2008 7:27 PM
To: Cox, Bruce
Cc: bryan rasmussen; Costello, Roger L.; xml-dev@lists.xml.org
Subject: Re: [xml-dev] XML Design for Diverse Data

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@gmail.com] 
> Sent: Wednesday, April 23, 2008 11:57 AM
> To: George Cristian Bina
> Cc: Costello, Roger L.; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] 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@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>