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: RE: [ubl-ndrsc] Minutes for 14 August 2002 UBL NDR SC meeting

The whole "what to name containers" discussion is interesting.  I think I
have a way (borrowed from the C type system) for resolving this.  It's a
generalization of the existing naming rules.

We currently have ObjectClass.PropertyTerm.RepresentationTerm -- tripartite
naming.  RepresentationTerm specifies the type of the property.  What I
believe we're running up against here is that our type system (as it stands)
is insufficient to model what in C is called "derived types" and what in C++
is generalized to "parameterized types".

An example of a derived type in C is array.  In order to do typechecking on
an array you have to know what it is an array "of".  Properly, you need to
specify something like "array of int" or "array of contact".

C++ generalized this idea to parameterized types.  In C++ you can define a
"generic type" e.g. a List<X> where X is the kind of thing to be contained
in instances of this type.  So List<int> is a type of list that can hold an

So I'm thinking that for our tripartite naming we (simply) need to expand
the capabilities of RepresentationTerm to (at a minimum) support our
container (derived) types.  I suggest two container types initially:
sequence and set.  List has too much of a data structure connotation for me,
whereas sequence is more abstract(leaving the door open to various
implementations).  Precedent here in the Standard Template Library (STL) for
C++ and the newer Java JDK 1.4 abstractions around strings -- the new
character sequence interface.

So I would suggest LineItemSequence for the example from the minutes.  I
guess Set and Sequence would have to become reserved words in our tiny
element naming scheme.

If we call the non-container types we've been dealing with to date something
like "direct" to distinguish them from derived types (containers,
parameterizable on a direct type), we could essentially expand
RepresentationTerm to be something like:

RepresentationTerm : DirectType
 | DirectType + DerivedType

DerivedType : "Sequence"
 | "Set"

So parsing LineItemSequence, "LineItem" is the DirectType and "Sequence" is
the DerivedType.  Together they constitue a RepresentationTerm.  This frees
you, should you need two such sequences at a particular level to distinguish
them via their PropertyTerm -- just the way we do with non-containers.  I
love it when things fit together!


-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com]
Sent: Wednesday, August 14, 2002 12:14 PM
To: ubl-ndrsc
Subject: [ubl-ndrsc] Minutes for 14 August 2002 UBL NDR SC meeting

Minutes for 14 August 2002 UBL NDR SC meeting

1. Roll call (quorum is 8)
     * Bill Burcham
     * Mavis Cournane     regrets
     * Mark Crawford      YES
     * Fabrice Desré      regrets
     * Matt Gertner       regrets
     * Arofan Gregory     YES
     * Jessica Glace      YES
     * Michael Grimley    YES
     * Eduardo Gutentag   YES
     * Eve Maler          YES
     * Sue Probert        YES (joined y:33)
     * Lisa Seaburg       YES
     * Gunther Stuhec     regrets
     * Paul Thorpe        regrets
     * Chris Ketels       awol

    We achieved quorum once Sue joined, and approved previous weeks'
    minutes at that time.

2. Acceptance of minutes of previous meeting

    31 July 2002

    7 August 2002


3. Adoption of agenda/schedule planning


    August 14:
    - Regrets from Paul Thorpe, Mavis Cournane, Matt Gertner;
      Sue Probert may be late
    - NDR review needed on LCSC distribution
    - NDR document review
    - OO and containership papers and methodology implications
    - Date/time: OO implications and comments received
    - Finish embedded documentation decisions
    - Identifier references
    - Local qualified vs. local unqualified vs. global elements
    August 21:
    - Jessica and Mike might have to leave early
    - Top-level message/element naming
    - Continue reviewing NDR draft 15 Section 10
    - All the deferred stuff from this week (need Gunther present!)
    August 28:
    - Regrets from Eve
    - NDR document review
    September 4:
    - Regrets from Paul Thorpe
    September 11:
    - Regrets from Paul Thorpe, possibly from folks in Geneva
    - NDR document review
    September 18:
    - Regrets from Gunther Stuhec
    - Approve documents for review distribution #3
    September 25:
    - No meeting; work on other UBL tasks instead
    October 1-4:
    - F2F #5 in Burlington, MA, USA
    - Everyone should try to reserve the Burlington Marriott

    A NDR document improvements (review every two weeks)
    A+ Embedded documentation NEARLY DONE
    A Code lists IN PROGRESS
    A Dates and times IN PROGRESS
    A Nested supplementary components IN PROGRESS
    A Identifier references and whether to pass content by reference
    A- Local vs. global elements
    B+ Containership IN PROGRESS
    B Updating guiding principles
    B Modnamver URN DONE
    B Modnamver schema location IN PROGRESS
    B Referencing of content, e.g. for attachments
    C Facets
    C Wildcards/open content
    C Nillability
    C Aggregation of similar information for XPath V1.0 addressing

4. Action item review

    - With Arofan, update the embedded documentation paper
      according to August 7 decisions.

    - Update the issues spreadsheet with Eve's comments.
    - Amend NDR document to add example code for Period.
    - NEW: Update NDR draft 15 with comments from our August 14 comments.
    - NEW: Review comments that have come in on the NDR document for the
      August 28 meeting.

    - Finish draft of code list document. IN PROGRESS
    - Send 0pt65 schema comments to LC SC. DONE
    - NEW: See if Mavis might be available for August 28 call.
    - NEW: Send draft principle for "generation of code" to the NDR list.

    - Write content referencing paper. IN PROGRESS
    - Review the date/time comments and recommend dispositions.
    - Send date/time NDR snippets to Mavis. IN PROGRESS
    - With Arofan, prepare samples of how to handle second-tier
      attributes. IN PROGRESS
    - Bring the donkey to Burlington!

    - NEW: Update modnamver and propose schema location solution. IN

    - NEW: Review 0pt65 release draft.

    - NEW: Look into readiness of planned August 16 LC release.

5. Other SC reports

    LCSC discussed in #6 below.

6. NDR review needed on LCSC distribution

    - Tim McGrath says the near-final draft will be ready Thursday
      morning for final review; comments are needed within 36 hours.

    We (Lisa in particular) are concerned that the quality and
    completeness of the release may not be up to par.

7. Review latest NDR document



    - We need to say who the audiences are for this document, and
      segregate the rules and guidelines per audience (e.g. the perl
      script vs. people writing external modules).  Ray Seddigh had
      commented on this in Minneapolis, and would be a good source of

    - Do we need a new, emerging guiding principle on "generation of
      code"?  Wherever we plan to generate XSD from a model, the model
      needs enough information -- and the rules need to be deterministic
      enough -- for the schema generation process to work.  We'll try out
      some wording.

    - Should Chapter 2, on the metamodel, be changed to reflect the new
      CCTS work?  We think that this shouldn't be updated until a new
      CCTS draft is put out, but the text (around line 173 in draft 15)
      should explicitly reference V1.8 of CCTS without requiring people
      to look at the References section.

    - It would be great if each succeeding version (other than formal
      distributions) were to show Track Changes (change bars etc.).

    - We think the element naming rules need more work around containers
      for series of like items.  The LCSC dropped the container for
      a series of ListItem elements because its dictionary entry was
      Order.LineItem.Details, and the truncation rules would turn it
      into a LineItem element (containing multiple LineItem elements
      that are technically different by being locally defined), which
      is wicked confusing.

      We agreed that we need a new rule for how to name the property
      term when its contents are a series of like items.  We agreed that
      the ordered/unordered distinction is not particularly important,
      so we discarded the option of using the word "Set" at all.  Our
      understanding is that multiple qualifiers are going to be allowed
      under the new CCTS situation.

      Straw poll:

      property qualifier property term   comments (preferred, acceptable)
      ListOf             LineItem        The term is false in this case
      ListOf             LineItems       Qualifier stuff too complicated
                         ListOfLineItem  p=1 a=0
                         ListOfLineItems p=0 a=2
                         LineItemList    p=5 a=2 We have a winner!
                         LineItems       p=0 a=4
                         LineItemsList   p=0 a=0

      We discussed whether LineItemList should use "List" as the term and
      "LineItem" (or whatever) as the qualifier, but decided that a
      "naked list" as a object class's property is just too vague a

      Some examples:

    - Section 10 UBL Messages:

      Bullet #1 (line 552) touches on a rule that's in modnamver but is
      not yet in the NDR document.  Should it appear in two places in the
      NDR document?

      Bullet #2 (line 554) is a little ambiguous as it stands.
      Obviously, different trading communities might extend a UBL
      purchase order message for their own uses, but it will have the
      "same business function" as the original one.

      Bullets #3-4 is similar to the element naming covered in lines
      284-285.  We need to be more explicit about whether verbs or nouns
      are meant, and what a "business function" is.

    - Rules for dictionary entry naming when applying context: We need to
      say that qualifiers should be added, and how to do that.

    We deferred all the items below.

			*		*		*

8. OO and containership papers and methodology implications

    OO paper:

    Containership paper:

9. Date/time: OO implications and comments received

    Date/time paper:

    Comments from Mike Grimley:

    Comments from Bob Miller (already discussed?):

10. Finish embedded documentation decisions

     See last week's minutes for previous decisions and status.

    - Where to insert all the documentation elements in each XSD
    - Make sure to at least provide a reference to the code list
      document, which puts some requirements on documentation.
    - Need to include rules on which fields need to be present for
      which XSD constructs.
    - The UBL schema modules need to incorporate XHTML Basic properly
      (e.g., declaring its prefix? importing the schema?).
    - We need to say explicitly what XHTML Basic version number.

11. Identifier references

12. Local qualified vs. local unqualified vs. global elements

13. Adjourn

     Adjourned at z:17.

Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC