No Subject

- DeliveryRequirementType
- DespatchLineType
- LineItemType
- OrderedShipmentType
- OrderLineType
- PackageType
- ReceiptLineType
- ShipmentType
- TransportHandlingUnitType

Any other top level business document (e.g. DespatchAdvice that
Tim pointed out) that uses any one of these types listed above
will have the recursive behavior described by Tim.

I'm not sure if recursive type usage is a good or bad idea, since
a model may need that recursive reference to reflect such an idea.
It need not cause infinity-processing (hanging) in the instance
space, since real document values could contain sentinel values
(e.g. empty strings, zeros, etc) to "terminate" the recursion.
This is done frequently in object-oriented programming, or just
plain implementation of data modeling.  But to complete the
specification, a proper sentinel value in the instance space 
will need to be specified or documented somewhere (e.g. 
absence of the element in the instance space to denote "end of
recursion", or other such mechanism).

The downside is that recursion, while familiar to developers,
is a rather abstract concept in the business world that could 
be simplified via other equivalent yet easier-to-understand 
mechanisms, such as ID value referencing (ie. some sort of 
"pointer" to dereference a late-generation of the pointed-to
values).

Which way to go would be, as Tim pointed out, a modeling issue.



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/


On Mon, 23 Jun 2003, Tim McGrath wrote:

>>Here are my findings when i reviewed these...
>>
>>...
>>>
>>DespatchAdvice still has some recursion (not a schema problem but a
>>modeling one).  A DeliveryRequirement has OrderLine, OrderLine has
>>LineItem and LineItem has DeliveryRequirement ad infinitum.

--------------060803060509000902070805--