Re: [ubl-dev] infinite loop

["Crawford, Mark" <mark.crawford@sap.com>]

Tim

There is a specific UBL NDR rule prohibiting infinite loops.

Mark Crawford
Standards Architect
GEPG Standards Management and Strategy
SAP Labs 
Mobile: (703) 485-5232

----- Original Message -----
From: Tim McGrath <tim.mcgrath@documentengineeringservices.com>
To: stephengreenubl@gmail.com <stephengreenubl@gmail.com>
Cc: David RR Webber (XML) <david@drrw.info>; G. Ken Holman <gkholman@cranesoftwrights.com>; UBL-Dev <ubl-dev@lists.oasis-open.org>
Sent: Fri Jun 25 16:17:40 2010
Subject: Re: [ubl-dev] infinite loop

surely the real practical answer here is that... yes, you can have 
infinite loops (as in any hierarchical data structures) - but  why would 
you?

if we can stop thinking as designers and think as users you realize 
no-one would ever do this in their invoices, order, etc...  As long as  
there is optionality on the associations then the depth is arbitrary.

the only times this ever comes up as an  issue seems to be when people 
use tools that generate sample documents - which is an artificial 
experience anyway.


Stephen Green wrote:
> It seems reasonable to conclude that the standard
> part of UBL is loose enough to allow most kinds of
> use. To actually use it you probably need more than
> just the standard. You need to further restrict it e.g.
> to restrict the number of nestings of AgentParty.
> There are standard ways to do this. Ken and I first
> produced a subset  by listing elements using XPaths.
> David led a  standard for restricting documents, also
> involving XPath and called CAM. I edited an in progress
> potential standard which can also be used with XPath to
> define restrictions and that is called  test assertion
> markup language. Ken led some of the work to
> standardise a more prevalent , similar technology to add
> restrictions beyond the schema called Schematron when
> it was standardised in ISO. All these help restrict
> UBL with rules or assertions beyond what the standard
> requires but to meet typical requirements for implementing it.
> Worth looking into all this, I expect.
>
> Regards
> Stephen D Green
>
>
>