RE: [ubl-dev] infinite loop

["David RR Webber \(XML\)" <david@drrw.info>]

Ken,

I know we disagree on this.  But I reiterate that the customer here is the business user - not XML technologists.

Another way to view this is that the standard should utilize simple associative references and not hardwired recursive linkages. That is how databases handle this.  EDI is not restrictive on one-to-many groupings like you seem to think - in fact there is also associative constructs like X12 L segments.

This is the traditional model based view of this - that for example you associate a person and role to an organization - rather than hardwiring a link to the actual person structure, that then contains a reference to organization and so on.

Back to the notion that the recursive link is optional and hence the tools should not traverse them.  

That is NOT what Oxygen and other tools are doing.  In fact you can see they only flag directly recursive nodes.

Indirect recursion they do not detect.  And in fact its an optical illusion because they are explicitly NOT traversing the structure otherwise they would recurse.  I've investigated this extensively.

So in Oxygen it will show this as recursive:

 <A>

    <B/>

    <C/>

    <D/>

    <A>

 </A>

but it will not see this as recursive

 <A>

    <B/>

 </A>

 <B>

    <C>

 </B>

 <C>

    <D/>

    <A>

 </C>

And what is more - the UI works because it does NOT scan the tree - but instead shows you just the top level nodes in the tree - and lets you manually drill down into node levels - one at a time.  So if you keep going - it will eventually recurse and fail when it runs out of memory.  I've seen that happen when you have several large schema in memory at the same time.

Again there is no way that a tool can assume that an optional XML structure component is recursive.  Most of the time they are not!

Thanks, DW

-------- Original Message --------
Subject: RE: [ubl-dev] infinite loop
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
Date: Fri, June 25, 2010 2:00 pm
To: UBL-Dev <ubl-dev@lists.oasis-open.org>

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


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org