Re: [ubl-lcsc][ubl-fpsc] second draft of example instances for 0.80-3.1

[Chin Chee-Kai <cheekai@softml.net>]

Stephen,

Very nice work on the sample instances.  I got a chance to
browse through them and have a question regarding the 
empty <cat:ID/>s sprinkled around.  The question is open
to the group to see what you guys feel about it.


Lists,

Most of the structures, such as AddressType, had many elements,
of which the empty ones are completely not instantiated.  That's
a perfectly logical way to handle them (whenever the minOccurs
permit) that results in compact instances.  I did the same in 
the Java classes that write data values entered by users into 
instance files as well.

However, because the minOccurs for IDs in some Reusable types,
such as PartyType and ShipmentType, are all "1", it necessitates 
the instances to carry empty <cat:ID/>s around, just like Stephen's
instances have done.  This has caused, for example, the 
last part of "JoineryDespatch_0_8-3-1_InstanceDraft_02.xml"
to contain an empty structure such as:

      <da:ActualShipment><cat:ID /></da:ActualShipment> 

But then for AddressType, for example, the ID is allowed to 
be un-instantiated (minOccurs="0").  There are other examples 
for both minOccurs="0" and minOccurs="1" in Reusable.

I seem to recall a 0.70 public comment question that also asked 
why there's a need for empty IDs in the 0.70 instances, but I 
don't recall the disposition from LC.

The question then becomes:  why the different requirement on
minOccurs for types defined in Reusable?

Could the minOccurs="1" cases an accidental use of schema's 
minOccurs facility to express a semantic requirement of "should 
have a non-empty string ID here", which ends up imposing on the
syntactic part of the instance that causes empty <cat:ID/>s a 
necessity?     Or could those minOccurs="1" Reusable types
just typos in the spreadsheet (that generated the same for
schemas)?

A related question that I have is also, and this may sound
really weird, but it seems to tie in with the unspoken rule
so far that we don't instantiate elements that have empty
values;  could all minOccurs be set to "0" for all the Reusable
and business documents to allow the syntactic possibility of
not instantiating them?



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


On Tue, 1 Jul 2003, Stephen Green wrote:

>>Greetings
>>
>>Please find attached a complete set of draft example instances for UBL 0.80.3.1
>>
>>Most of these are updates of the 0.70 examples
>>
>>New examples are included for Order Change ('office' scenario), Order Cancellation ('office' scenario), and Receipt Advice ('office' scenario and 'joinery' scenario).
>>
>>There are still outstanding issues regarding 0.80 so there may be changes for that reason.
>>
>>One purpose of these instances is facilitate further scrutiny so please make comments where necessary. Already the process of updating and creating these examples has led to some issues being raised and these have been posted to the LCSC list.
>>
>>All the best
>>
>>Stephen Green
>>
>>You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php
>>
>>