Re: [ubl-lcsc] Proposal for 1.0 alpha draft 9 model

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

see comments in line...

NB: Gunther and Garrett, can we get your input into the question of what
Rep. Terms and CCT schema we should be using?

Stephen Green wrote:
> Tim and LCSC
>
> Hi
>
> I'm attaching a proposed version of or towards the draft 9 model. 
>
> It has the following neccessary changes to draft 8 (the second being neccessary to draft 7 too):
>
> Reusable: cardinality of OrderReference.BuyersID, OrderReference.SellersID, OrderLineReference.BuyersLineID and OrderLineReference.SellersLineID changed to 0..1
>
> Reusable: cardinality of PaymentMeans.Payment changed to 0..1
>
> Some other points following on from my previous mail (Sorry about the obvious mistake below - 'Two more matters' should of course be 'Three matters'):
>
> Item 3 below, I realise is inaccurate in that, although the cardinality of the Party Identification. ID is 1..1, the cardinality of Party.PartyIdentification is 0..n, making it neccessary to have the latter as an ABIE if one wishes to avoid having a 0..n BBIE.
correct - this is the 'possible empty container' problem.
> If Lisa's point about use of 'Identification' in the ABIE's name means a change to the name, I'd add that the same should probably, I think, be done to 'ItemIdentification' too (which is definitaley an ABIE).
i believe the rule does not apply the PropertyTerm is 'PartyIdentification'
and 'ItemIdentification' not just 'Identification'.
> Bill has pointed out that the proposed new CCTs haven't yet been adopted by ebXML CC, so we probably have to do without them in 1.0 beta. If so and we need to create GUIDs some other way, can we leave this requirement out of the model and (sorry Chee-Kai) move it into the tools area? That way we can concentrate on the post-modelling work, in accordance with the schedule.
Can we just ignore these three additional CCTs ? - following Garretts email,
are there other chnages we need to look at.  For example, if we are to use
the three-part CCT schemas, then i suspect the mapping of Representation
Term to CCT should be done by there and not in our scripts.  Until we get
a clear guideline from Garrett or Gunther i am not sure we have done all
we need to do.

w.r.t. GUID, i favour the idea of creating this as an ABIE - which is really
just another way of expressing secondary CCTs anyway.

I hope this can all be sorted by or on Tuesday so that I can be confident in generating 1.0 alpha example instance drafts before Friday.

All the best

Steve





  

"Stephen Green" <stephe_green@bristol-city.gov.uk> 10/05/03 12:14 PM >>>
        

Two more matters for draft 9:

1. PaymentMeans. Payment should probably be 0..1, not 1..1  (sorry - probably my fault again)

2. Payment needs consideration re example content for the example instances

3. Shouldn't Party.PartyID (Party. PartyIdentification) be a BBIE since it has cardinality 1..1 ?

Thanks

Steve

  

"Stephen Green" <stephen_green@bristol-city.gov.uk> 10/05/03 11:03 AM >>>
        

Tim

For draft 9 we will also need to correct an error in my latest amendment in draft 8: BuyerID and SellerID in OrderReference and OrderLineReference need cardinality 0..1 rather than 1..1  These are the cardinalities of the referenced ID's (to allow for either SellerID or BuyerID being available but not both). 

That is providing there is no objection to the draft 8 proposed amendment (which was to correct there being both Seller__.IssueDate, etc and Buyer__.IssueDate, etc in draft 7).

This problem was found as I was preparing the example instances. To continue with this it would be ideal to have these errors fixed. Sorry I missed this in draft 8.

Would you propose which other changes might go into draft 9 and I could get started on the model, if you wish.

Steve

  

Tim McGrath <tmcgrath@portcomm.com.au> 10/05/03 06:52 AM >>>
        

Thanks for these. it is good to see the NDR folks are keeping us honest.

These need to be disposed of at the next LCSC meeting.  meanwhile, see 
my comments inline...

Lisa-Aeon wrote:

  

More issues/comments from the NDR Schema Review Team (all of these issues
will be on the agenda of the next LCSC and NDRSC teleconference calls,
depending on which group needs to look at them):

In Reusable

PartyType includes an element called PartyIdentification. Shouldn't this be
PartyID? Also, it is defined as a sequence of a single 'ID' element. I don't
recall seeing the latest spreadsheet so I'm not sure what may have caused
this naming/structure.
 

    

We don't generally abbreviate ABIE names so te 'Identification'->"ID" 
formula did not kick in. The reason is that PartyIdentification is an 
ABIE nt a BBIE.  The Property Term Noun is "Party Identification" not 
just "Identification".

I have checked the latest NDR checklist and it appears we dont 
explicitly have these abbreviation rules anymore.  the nearest i could 
find was:

[GNR4] UBL XML Element, attribute, and Simple and complex type names 
MUST notNOT use acronyms, abbreviations, or other word truncations, 
except those in the list of exceptions published in Appendix B.

I cannot see Appendix B but i think what we have is correct.  

  

CoreComponentTypes:

ID and IDREF are used throughout, due to definition of Common Attributes.

    

the last checklist i have (sept 17th)  says...
[R 105] ID/IDREF MUST NOT be used. [Ed Note - on hold]
[R 106] Key/KeyRef MAY be used. [Ed Note - on hold]

Is it still on hold?  if not,  is this an issue that can be resolved at 
the same time as the CoreComponentTypes.xsd discussion?

  

Order:

TotalPackagesCountQuantity. Wouldn't 'Count' and 'Quantity' be considered
similar enough to drop the 'Quantity'?
 

    

good idea, except the CCTS rule is that we would have to drop the 
'Count' (the Property Term) not the 'Quantity' (the Representation 
Term). So it would become TotalPackagesQuantity - which works just as 
well.  We can achieve this by changing the Property Term of Count to be 
Quantity.

If we want to do this is should be part of 'draft 9'.

  

++++++++++++++++++++++++++++++++++++++++++++++++++++
Lisa Seaburg
AEON Consulting
Website: http://www.aeon-llc.com
Email:  lseaburg@aeon-llc.com
Alternative Email: xcblgeek@yahoo.com
Phone: 66-562-7676
Cellphone: 662-501-7676

"If you obey all the rules, you miss all the fun."
                      -Katharine Hepburn
++++++++++++++++++++++++++++++++++++++++++++++++++++



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Versin: 6.0.515 / Virus Database: 313 - Release Date: 9/1/2003
 

To unsubscribe from this mailing list(and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php.

    

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to 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