[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] infinite loop
At 2010-06-25 09:20 -0700, David RR Webber \(XML\) wrote: >I believe this will not assist Elisa at all. > >You provided a technology answer to a business users needs. I respectfully disagree, David, and I appreciate the opportunity to compare and contrast these opinions. > >I'm working on UBL xsd files to obtain a tree viewer of the > >documents,but the algorithm enter into an infinite loop because of > >the structure of the xsd. > > >For example, in the Order document there is the element "Signature" > >of type: Signature type. Signature type,that is a complex type, > >contains the element "SignatoryParty" of type PartyType. PartyType, > >that is a complexType, contains AgentParty that is a PartyType and > >will contain another AgentParty element...and so on. > >Is it true? I don't understand the meaning of these circular calls. > >Regards Elisa > > From a business users stance - they expect standards to be designed > to work with a broad range of common tools - and not require > special features to operate, or worse, break commonly accepted tools. What special feature are you speaking of? It is a *bug* that a tool would infinitely traverse a recursive structure that is only optionally recursive. It is a bug exactly because it is recursive and the tool isn't handling such a construct appropriately. >Perhaps you can suggest a tool that will allow Elisa to view the >business information structure tree view without looping? Sure! How about oXygen? It is a conforming XML tool. For the UBL structures, how about my own HTML reports of the UBL structures? http://www.CraneSoftwrights.com/resources/ubl/index.htm#ubl2modelreport That gives you a view of the business information structure tree without looping. >And then of course a tool that will generate working XML examples >without looping, I just opened oXygen up now, opened up the UBL Invoice schema, and generated a sample instance with the press of a button. No hassles. >and then a processing tool that will not loop when trying to read >the document in. Documents are never recursive. Models are recursive. Documents may have embedded references to identical structures, but an XML document is never recursive because it always stops the descent at some point (or it wouldn't be XML well-formed, thus it wouldn't be XML). >BTW - docbook and html examples cannot be used to relate to business >transactional information exchanges. There is a significant >difference between writing content for human reader consumption - in >the classic sentence/paragraph/chapter/publication model - and >creating content for computer machine processing for B2B processes - >using the typical one-to-many iterative deterministic structured >sections of messages by context - so the patterns are predictable and known. > >I stress iterative deterministic as in a business transaction >purchase order, rather than recursive and non-deterministic as in >the chapters in a publication - such as traversing a topic on wikipedia. And *I* stress that my examples are perfectly illustrative of my point that *any* deterministic decision will not meet the needs of *all* users, regardless of the subject domain. Any arbitrary choice made by the UBL committee of a deterministic depth of embedded references to like-structures that exist in the real world will be too few for *someone* in the real world who needs at least one more than what the committee provides. I thought the HTML/DocBook shows this: The HTML designers made an arbitrary choice. The DocBook designers leave the choice to the XML author. The HTML choices are insufficient for people who need seven or more levels of depth of headers. The DocBook choices accommodate all users of any level of depth. Why are real world business documents immune to such situations? One of the problems with flat pre-deterministic messages structures as I understand structures like EDI messages to represent is, I believe, the arbitrary nature of the choices that *someone* made as to how limited the determinism is. One of the benefits with recursive structures in XML is, I believe, the ability for users to use as many levels of depth as they need. Who thinks real-world business is deterministic? The UBL committee has no idea how many levels of depth of embedded like-structured pieces of information people in the real world are going to need. By using recursive structures in XML we can support anyone's requirements in this regard. Another example, that by using XML namespaces and UBL customization extensibility, is the UBL structures are better adaptable to real-world situations we could never anticipate from inside a committee. I hope this is considered helpful. For readers of the archive like Elisa who have not had to think about such things, I believe the discussion is very important. . . . . . . . . . . . . Ken -- XSLT/XQuery training: after http://XMLPrague.cz 2011-03-28/04-01 Vote for your XML training: http://www.CraneSoftwrights.com/u/i/ Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ G. Ken Holman mailto:gkholman@CraneSoftwrights.com Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/u/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]