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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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

Subject: [ubl-ndrsc] FW: deterministic generation of Dictionary Entry Names

Tim M. asked me to forward this.  He can't post to ndrsc...
-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Wednesday, February 13, 2002 7:48 PM
To: Burcham, Bill
Cc: 'ubl-ndrsc@lists.oasis-open.org'; ubl-lcsc@lists.oasis-open.org
Subject: Re: deterministic generation of Dictionary Entry Names

Thank you (again) for this insight. i have taken the liberty of adapting your snippet and applying some of the new concepts emerging from our analysis.

The LCSC has been struggling with the use of 'representation term'. i attach a position paper whih outlines some of the issues and proposes a solution.  This has not yet been distributed to the LCSC, so they may wish to comment as well.

My feeling is if we merge your ideas with those of this paper we end up with a practial solution along the lines of my revised snippet.

There are some interesting conclusions to this...

a. Representation terms for aggregates are an unlimited set (there will be one for each re-usable type).  This makes sense to me, but requires a broader interpretation of the ebXML CC rules for aggregate BIE representation terms.(we get rid of that pesky 'Details'!)

b. the property term start to look a lot like 'attributes'

c. sometimes a property term looks like a 'foreign key'.  that is, they reflect the role when used as an instance of another type. (see the various roles of Contact).  this makes sense and points clues to handling 'context' as well!

d. we may not need 'propertyqualifier'.

e. we may not need 're-usable type' as it is derviable from the representation.

I would greatly appreciate a final position on this this week so we can publish our first library model next week.  So please speak up!

Burcham, Bill wrote:
40AC2C8FB855D411AE0200D0B7458B2B07344AD6@scidalmsg01.csg.stercomm.com type="cite">
I took a snippet of The Spreadsheet (as it existed last week) and did two things to it:
a) I added a column for the "CC Dictionary Entry Name".
b) I added a column called "Property Qualifier"
The CC Dictionary Entry Name has a (not very good) formula to compute the dictionary entry name.  Needs 1) separators added, 2) search backward for nearest "object class" -- for now each group of property definitions has their "object class" hardcoded in their formula.
I added the "Property Qualifier" column so that the names for properties would conform to the NDR SC rule for dictionary entry names for properties -- the one we arrived at on the last day of the F2F, to wit: [Qualifier] PropertyTerm [RepresentationTerm].  Before I added the column, the spreadsheet was using the "object class" column to define parts of property names.
So if you look at this spreadsheet, you'll see that property definitions do not use the "object class" field -- good.  Also, (reusable) type definitions=CC's=BIE's use only the "object class" field for their names.
I think it's really important to do these two things to The Spreadsheet soon.

tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142 




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

Powered by eList eXpress LLC