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] Minutes for 17 April 2002 UBL NDR SC meeting

Minutes for 17 April 2002 UBL NDR SC meeting

1. Roll call (quorum is 8)
     * Bill Burcham       YES
     * Mavis Cournane     YES
     * Mark Crawford
     * Fabrice Desré
     * Matt Gertner       YES
     * Arofan Gregory     YES (joined x:10)
     * Phil Griffin       YES
     * Jessica Glace      YES
     * Eduardo Gutentag   YES (left x:58)
     * John Larmouth
     * Eve Maler          YES
     * Sue Probert
     * Lisa Seaburg
     * Gunther Stuhec     YES (joined y:27)
     * Paul Thorpe        YES

    Quorum not reached as of x:04; we proceeded informally.  We reached
    quorum at x:10.

2. Acceptance of minutes of previous meeting

    10 April 2002 F2F meeting:


3. Adoption of agenda


4. Status of NDR document production/outline
    Mavis's outline from last time:
    She will update when there are more changes to be made.

5. Tag structure decisions
    SWIFT comments:

    Global attributes:

    - Gunther has designed some UBL-specific global attributes into
      the schemas, but we're unsure that (some of) these attributes are
      well enough motivated.  Ideally these sorts of things should be
      accounted for in the spreadsheet, and therefore the methodology.

    - We don't currently say when to use these, besides implying that
      they should be used for "global ID" attributes.  There are two
      considerations: when to choose existing external global attributes
      like xml:lang, and when to choose to design UBL-specific global
      attributes.  Right now, we don't see any particular benefit to
      making "common properties" of all elements be declared as global
      attributes.  The schema code doesn't get any shorter (however,
      we imagine that the dictionary could have a single entry instead
      of one entry per assignment of a local-but-common attribute to
      each element).

      We propose the following rule: A global attribute should be used
      only when its semantics are absolutely unchanged no matter what
      element it's used on, AND it's made available on every single
      element.  This goes for both external and UBL-specific ones.  This
      allows common attributes that are everywhere but are *not* global,
      and that need documentation of their meaning in each XML
      environment in which they're used.

      New ACTION: Eve to send mail to the LC SC outlining the question
      about the existing global attributes and asking about the best way
      to justify them (and others).  This should be phrased in
      XML-neutral terms (e.g. global attributes as common properties of
      all objects).

    - We're happy to say that UBL-specific global attributes should be
      named just like regular attributes and subelements (that is, as
      properties of an object class).  Note that, by definition, the name
      of such a property *must* be consistent across all objects.

      New ACTION: Mavis to put the two proposed rules in the tag
      structure/NDR document.

    Mixed content:

    - We agree that mixed content in business documents is basically bad
      news.  Only description fields that need some "publishing freedom"
      are likely to need mixed content, such as product descriptions in
      catalogs.  We need to add a rule about avoiding mixed content in
      most cases.  The reasons it's bad are:

      . White space is difficult to handle and complicates processing.
      . Mixed content models allow little useful control over cardinality
        of elements.

    - We're not sure we like "Prose" as an RT.  Other options we've
      discussed are: Text (already used, though it's our default and it
      gets elided from actual tag names), Poetry (kidding), Narrative,
      Mixed, AnnotatedText, Pub[lishable]Text, [X]HTML.

      ACTION: Eve to ask the LC SC for a variety of examples of content
      that needs "publishing" information in them, e.g., bold, italic,
      paragraphs, etc.  We suspect that XHTML is sufficient for all such
      needs, and we want them to try and prove to us that this isn't

    Empty elements:

    - Can we confirm that we don't believe in empty elements?  VOTE: Do
      we accept Gunther's rationale for why empty elements should not be
      used?  Unanimous YES.

    Complex types that contain <simpleContent>:

    - Gunther has conventionally used the infix "Content" for the simple
      type corresponding to the content of a complex type that has simple
      content.  For example, CodeContentType is a simple type trivially
      restricting xs:token, and it's used in setting up CodeType, which
      is a complex type that adds attributes to an element containing a

    - There are several questions about the current approach.
      Considering that most of the simple-content types are trivial
      restrictions of an XSD type, do we really need these?  Can the
      CoreComponentType.xsd file merely have these reference the XSD
      type directly in some/all cases, which amounts to using an
      anonymous type in a sense?  There is a proliferation of
      types (CodeListAgencyIdentifierType, CodeListIdentifierType,
      CodeContentType, etc.).  Having a UBL-named type may be useful
      for handling contextualization (through derivation) and also,
      just in general, for data binding (schema compilation and database

    - Gunther asks about how users can set facets on our types.  Arofan
      points out that the LC SC currently isn't capturing very precise
      facet-type information, such as how long a number is.  Gunther's
      examples are: setting the number of digits in the fraction of an
      amount (e.g., a price), and constraining identifiers to the number
      of characters/digits that are exactly allowed.  Arofan wants to
      define some facets out of the box.  He notes that xCBL did a lot
      of work on this and we can probably use their ready-made types.
      Gunther has also done some work on this.

      New ACTION: Arofan and Gunther to take up with the LC SC the
      potential business requirement for making types more precise.

    - How to name complex types, simple types, and complex types with
      simple content: Deferred!

6. RT/CCT comments and status
    Bill's latest effort along these lines:
    CCSD discussions on this point:

    We noted that the CCSD group seemed to be going in the direction of
    one-to-one mappings, which raises (to us) the question of why you
    need both.  Arofan is still signed up to propose a list that migrates
    structural characteristics from RTs to CCTs and shows which (possibly
    multiple) RTs can be served by each CCT.

7. Code lists

8. Elements vs. attributes

9. Action items and prioritizing our next chunk of work

    Summary of work to be done:

    A External recommendations for changes to CCTS [IN PROGRESS]
    A Code lists
    A Modnamver
    A NDR document production [IN PROGRESS]
    A Review the purchase order schema design [IN PROGRESS, sort of]
    A Officially decide elements vs. attributes
    A Officially decide empty elements [DONE]
    B Tag structure [NEARLY DONE]
    B Containership
    B Fixed vs. varying types
    C Dates and times


    April 24: Code lists, tag structure, RT/CCT comments (1hr)
    May 1: (2hr)
    May 8: (1hr)
    May 15: (2hr)
    May 22: (1hr)
    May 29: (what else?), approve NDR document for distribution (2hr)
    June 5-9 (the F2F meeting itself, if all goes according to plan)

    Current ACTION items:

    - A: Review the modnamver paper, the examples, and the 0.64 schema
    - A: Read Matt's types paper and see if we want to prioritize it

    - A: Tag structure/NDR changes

    - A: Code list paper
    - A: Help Mavis with Word styles in NDR document
    - A: Get LC SC feedback on global attributes
    - A: Get LC SC feedback on "prose" needs

    - C: Role model paper

    - B: Containership paper
    - A: Attempt a more specific RT/CCT proposal
    - A: (with Gunther) Take up facet discussion with LC SC

    - C: Date/time paper
    - A: (with Arofan) Take up facet discussion with LC SC

10. Adjourn
     Adjourned z:00.

Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com

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

Powered by eList eXpress LLC