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

[George Cristian Bina <george@oxygenxml.com>]

I believe there is a wrong problem here... One does not say let's use 
NVDL and make compound documents and then let's see how we process them 
and what fails in our current processing chain. NVDL is here to support 
those people that use compound documents and that need those documents 
for various reasons. It is not NVDL that should trigger the need for 
compound documents, as it is not XML Schema or Relax NG what triggers 
the need for using XML documents. NVDL is the solution once you have the 
problem of validating compound documents.

Best Regards,
George
--
George Cristian Bina
http://www.oxygenxml.com

bryan rasmussen wrote:
> I much prefer this method that George discusses, basically extracting
> the namespaces that you want into a new instance and serializing (I am
> understanding that correctly right? It's generally what I prefer to do
> as I find it 'safer'). I suppose though that there is a problem
> involved in that if I bring in two namespaces, one with a document
> element and one that extends the first, how do I serialize the
> extending namespace. Obviously I need to write code to deal with each
> instance (no problem doing this, just want to be certain we agree  -
> and of course can always just drop non-understood namespaces)
> 
> I agree that theoretically Roger's observation that
> 
> "Thus, if a programmer writes code assuming the first (closed) content
> model then his code is likely to fail.
> 
> The problem is with the programmer's misunderstanding of the content
> model, not a problem with NVDL."
> 
> is sort of correct, instances in which it would not be correct would
> be instances in which the content model was originally specified
> without explicitly stating that one could extend every element node,
> as is generally the case. It would require a really far thinking ERP
> solution to have thought this out.
> 
> In such a case if someone added in NVDL( and did not use the method of
> extracting via XSL-T) without knowing all the constituent parts of the
> system that would be dealing with the XML would be up to handling
> anything thrown at it, they might be inviting problems.
> 
> Furthermore while Roger would be correct in some instances that it
> would be the programmer that made a mistake there is a significant
> portion of the IT industry that seems of the opinion that programmers
> make mistakes quite often and that tools and methods should be
> designed with this in mind, and to protect them from accidentally
> making mistakes when things are difficult to understand. I believe
> that NVDL, which as I've said previously would be really useful for
> Compound Documents, does not seem to help the programmers who need to
> deal with XML data and process it for their big data silos and
> whatnot. Rather the opposite I feel.
> 
>  As another example of the problems likely to occur in NVDL usage,
> which do you think is the better fragment of XSL-T:
> 
> this
> <xsl:template match="payment">
> <tr><xsl:apply-templates/></tr>
> </xsl:template>
> 
> 
> as opposed to this
> 
> <xsl:template match="payment">
> <tr><xsl:apply-templates select="paymentpart/currency |
> paymentpart/amount"/></tr>
> </xsl:template>
> 
> 
> without extraction of the relevant namespace the validation which is
> now very free but not extensible has affected the transformation which
> is now very constricted and non-extensible, because obviously the
> stylesheet writer should write stylesheets defensively or risk having
> the business value of the Order presentation be ruined by the addition
> of lots of other stuff creeping in (this example as all examples is
> open to the conclusion of Roger that it is the programmers fault, or
> to the conclusion that systems and tools must be kept up to date as
> new extensions are allowed in[which I've seen in various projects can
> be problematic to coordinate over a large enough set of business
> partners]).
> 
> The point is that there is an intrinsic connection between the
> predictability of the data format and the amount of leeway one can
> allow oneself in programming up against it.
> 
> Now if one uses the method of extracting just the data we want to
> process in a pipeline of our application I think in most application
> scenarios we run into the question:
> 
>  why did you want me to use NVDL again?
> 
>  I use NVDL and then extract the data?? Why not just extract the data
> and validate it with good old technology X?(with X probably standing
> for XML Schema)
> 
>  I don't think the validation freedom is going to be enough of a sell
> to those people, they tend to be conservative and not concerned with
> freedom; what they want is not validation freedom or ease, what they
> want is assurance that the data entered into their systems at all
> parts are valid. I don't see NVDL providing any benefit there, as
> opposed to technologies like Schematron which do provide this benefit.
> 
> There are other problems in the chain of things that happens in such a
> validation of multiple namespaces that I don't have time to go into
> here. Suffice to say that while I prefer the following procedure (only
> for 'data' formats:)
> 
> Extract Namespace X, serialize -> Go to Validation for Namespace X
> Schema -> Go to Validation for Namespace X Schematron -> other
> validation etc.
> -> processing of serialized Namespace X instance
> 
> I realize there are serious drawbacks for handling extensible formats
> in this way as well.
> 
> Cheers,
> Bryan Rasmussen
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Apr 23, 2008 at 1:48 PM, George Cristian Bina
> <george@oxygenxml.com> wrote:
>> Hi,
>>
>>  One should be able to obtain the document fragments that go to each
>> validate action based on the NVDL script (the result of the dispatching part
>> of NVDL).
>>  An XSLT 2.0 implementation of NVDL that performs only the dispatching part,
>> that is it extracts document fragments associated with each schema is
>> available as part of oNVDL:
>>  http://www.oxygenxml.com/onvdl.html
>>  One can use the NVDL as a filter to get only the desired document fragment
>> and pass that for further processing to the code that expects only that as
>> input.
>>
>>  Best Regards,
>>  George
>>  --
>>  George Cristian Bina
>>  http://www.oxygenxml.com
>>
>>
>>
>>
>>
>>  Costello, Roger L. wrote:
>>
>>> Hi Bryan,
>>>
>>> Here's a summary of Bryan's message:
>>>
>>> Consider this XML:
>>>
>>>   <payment>
>>>       <paymentpart>20</paymentpart>
>>>       <paymentpart>45</paymentpart>
>>>   </payment>
>>>
>>> A programmer may write code to sum each value in <payment>, e.g.
>>>
>>>   sum = 0
>>>   loop through payment
>>>      sum = sum + paymentpart
>>>
>>> With NVDL new elements may be introduced within <payment> and thus the
>>> programmer's code may fail.
>>>
>>> Bryan, is that a fair summary?
>>>
>>> Here are some thoughts:
>>>
>>> NVDL changes this content model:
>>>
>>>   <payment>
>>>       <paymentpart>20</paymentpart>
>>>       <paymentpart>45</paymentpart>
>>>   </payment>
>>>
>>> Into this content model:
>>>
>>>   <payment>
>>>       -- zero or more other-ns elements --
>>>       <paymentpart>20</paymentpart>
>>>       -- zero or more other-ns elements --
>>>       <paymentpart>45</paymentpart>
>>>       -- zero or more other-ns elements --
>>>   </payment>
>>>
>>> That is, it changes a closed content model into an open content model.
>>>
>>> Thus, if a programmer writes code assuming the first (closed) content
>>> model then his code is likely to fail.
>>>
>>> The problem is with the programmer's misunderstanding of the content
>>> model, not a problem with NVDL.
>>>
>>> What is exciting to me is that NVDL changes all schemas (XML Schema or
>>> Relax NG) from a closed content model to an open content model, without
>>> any changes to the schemas!.  To state it a bit dramatically:
>>>
>>>     NVDL unlocks closed schemas!
>>>
>>>
>>> Comments?
>>>
>>> /Roger
>>>
>>> _______________________________________________________________________
>>>
>>> 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
>>>
>>>
>>  _______________________________________________________________________
>>
>>  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
>>
>>
> 
> _______________________________________________________________________
> 
> 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
>