OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl-dev] infinite loop


Ken,

I believe this will not assist Elisa at all.

You provided a technology answer to a business users needs.

>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.

Perhaps you can suggest a tool that will allow Elisa to view the business information structure tree view without looping?  

And then of course a tool that will generate working XML examples without looping, and then a processing tool that will not loop when trying to read the document in.

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.  

Thanks, DW

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

Them's fightin' words, David! I wouldn't want Elisa to be left with
the wrong impression.

Recursion is often optimal in XML design, and UBL's use of it
reflects the nature of the business objects needed in UBL. Many real
world relationships are recursive in nature and not contrived at all.

As Mark says, the only "bad" recursive design is that without an
escape of having the recursive reference optional.

Elisa, please understand that when using a tool that infinitely
traverses a construction whose recursive members are optional, the
problem is with the tool and not the information design. *Never*
ignore a recursive reference because it is likely to be very
important. *Often* a recursive reference is more efficient and more
natural than contriving an arbitrary number of levels of depth, only
to find you haven't created enough for a particular user's requirement.

I recall the old adage "any piece of string cut to length will be too short".

Think of document design: in HTML you have H1 through H6 for
headings of different depths of your information, but what if you
need a seventh level of depth? You are stuck because the HTML
designers made the arbitrary decision to stop at six levels of
depth. What is so special about six? Whereas in DocBook the SECTION
element recursively and optionally references the SECTION element so
as to allow you to have an arbitrary depth to your information.

I think the UBL choice of recursive constructs is meaningful,
efficient, optimal, very appropriate, and not at all contrived.

You just need to use an XML-aware tool that understands how to work
properly with recursive constructs.

I hope this helps.

. . . . . . . . . . Ken

At 2010-06-25 07:22 -0700, David RR Webber \(XML\) wrote:
>Elisa,
>
>I concur.
>
>Unfortunately these loops occur in many many places in UBL - and so
>you will have to find Schema tools that detect and ignore them.
>
>While conceptually in theory in modelling world it is possible to
>have these - and a convenience for modellers - in real world actual
>cases - uses tend to feel contrived.
>
>And for those few cases - there are better ways of handling them
>than using recursion to do it.
>
>Trying to use your model view as the information exchange view
>produces XML exchanges that do not necessarily reflect the optimal XML pattern.
>
>Thanks, DW
>
>-------- Original Message --------
>Subject: [ubl-dev] infinite loop
>From: elisa blasi <<mailto://elisablasi@gmail.com>elisablasi@gmail.com>
>Date: Fri, June 25, 2010 3:53 am
>To: <mailto://ubl-dev@lists.oasis-open.org>ubl-dev@lists.oasis-open.org
>Hi,
>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


--
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]