RE: [ubl-dev] infinite loop

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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