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

[Tim McGrath <tmcgrath@portcomm.com.au>]

Thanks anne for pulling all these bits together.  In summary what we 
have is...

a. we have dramatically reduced the number of mandatory ID BIEs in the 
models and subsequent schemas.  This addresses the face-to-face 
resolution of using case by case assessment of the use of  the use of IDs.
b. Some still exist as optional IDs when there is not apparent other way 
of uniquely identifying the ABIE it belongs to. (e.g. AllowanceCharge 
and Address )
c. In some of Stephens' instances he has chosen to specify the ID 
element even though it has no value and it is optional (e.g. 
JoineryInvoice contains.  However, I think we don't have to do this. For 
example,
        <cat:Address>
                <cat:ID/>
                <cat:Street>Marsh Lane</cat:Street>
                <cat:CityName>Nowhere</cat:CityName>
                <cat:PostalZone>NR18 4XX</cat:PostalZone>
                <cat:Countrysubentity>Norfolk</cat:Countrysubentity>
            </cat:Address>
- i don't think we need the "  <cat:ID/> " tag at all - is that correct?


Anne Hendry wrote:

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

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160