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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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


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


Hi Chee-Kai,

Yes, comment i.1 seems to relate to this.  It asks"

"Why do I have to keep using the <cat:ID> element on everything, even 
when it is not being used? This is especially obvious in the supplied 
example OfficeSupplyOrderInstance.xml . By my count 40 out of 49 times 
the element is used, it is empty."

There was no proposed solution, but the 'QA Comment' field states:

"Good comment.  Relates to NDR discussion of whether these Ids are 
essential.
 In practice, people don't use them.  Why are we mandating something 
that isn't
used by most people.  Related comments above."

then the F2F disposition states:

"Identifiers usually only used when there is the potential for confsion 
between them.
OO design has this concept of an ID for each object, so mandatory IDs 
for ABIEs
to uniquely identify instance.  In real world, uniqueness identified by 
several coponents,
not just one number.  Gunther's CCC paper touches on this?"

and the post-F2F column adds:

"LCSC: UBL UIDs are being removed for 0p80"

So I suppose the question is whether Gunther's CCC paper did clear this 
up or not.
(I'm not sure how/if the post-F2F statement applies here.)

Then, comment 24.3 states:

"Many elements have an ID, which is always mandatory. I assume there is 
an design principle lying behind that. For practical application this 
seems to be a bit strange. Assuming an order transaction issued by a 
small company without a high sophisticated ERP system I wonder, how all 
these IDs have to be generated. I cannot see how to equip every address 
or contact with a unique ID in the above mentioned case."

Then the pre-F2F discussion was:

"This came out of the modeling excercise and conforms to the position 
Gunther is taking on OO approach to schema design.  The pupose was to 
differentiate ABIEs by combining common types - those required mandatory 
IDs, but not all.  Maybe this is now to differentiate?

QA: If it is agreed that this is a design principle, then NDR should 
update document to clarify whether the element ID should be mandatory.   
Logic behind this needs to be clear for those developing schemas.  Tim: 
Yes, we need a policy on this."

and the F2F disposition was:

"Use of IDs for every ABIE needs to be reviewed on a case-by-case basis."

and the post-F2F discussion has been:

"Made mosy Ids optional except for Lines on documents and for Party.
i.e. where it would not make sesne not to have an ID"

and I'm not sure how it's been dealt with in the .80 model.
Tim or Sue may have later info about this.

-Anne

Chin Chee-Kai wrote:

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




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