Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Design for Diverse Data
 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@o...> 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@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 >>> >>> >> _______________________________________________________________________ >> >> 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 >> >> > > _______________________________________________________________________ > > 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 > 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
