[ubl-ndrsc] Minutes for Naming and Design Rules SC meeting 14 November2001

["Eve L. Maler" <eve.maler@sun.com>]

1. Roll call

    Quorum is 8, not 9; Kelly has dropped off.  Quorum not reached as
    of x:06; we proceeded with an informal discussion.

    Bill Burcham       YES (joined at x:15)
    Doug Bunting
    Dave Carlson       YES
    Mark Crawford      YES (joined at y:08; gave us quorum)
    John Dumay
    Matt Gertner
    Jack Gager
    Arofan Gregory     YES
    Eduardo Gutentag
    Eve Maler          YES
    Dale McKay         YES
    Sue Probert
    Marion Royal       YES (joined at y:11)
    Gunther Stuhec     YES
    Mike Rawlins       YES

    We briefly discussed changing our meeting times around in order
    to accommodate Australian participants (currently just John
    Dumay), but ultimately felt that we should keep to our original
    schedule at least through our first deliverable.


2. Acceptance of minutes of 7 November 2001 meeting

    http://lists.oasis-open.org/archives/ubl-
    ndrsc/200111/msg00026.html

    Deferred until we have quorum (but then forgot once we reached
    it :-). Will pick up next time.


3. Adoption of agenda

    Adopted.


4. Compile and rank use cases

    Mike sent out a set of use cases:
http://lists.oasis-open.org/archives/ubl-ndrsc/200111/msg00063.html

    Dale sent out a use case:
http://lists.oasis-open.org/archives/ubl-ndrsc/200111/msg00066.html

    The variability in many of Mike's use cases has to do with
    whether the schema is used to guide or check creation/use.
    Arofan pointed out that even people who use Notepad to create
    instances can check validity using a command line.  Gunther noted
    that the SAP system allows you to avoid validity checks for
    performance reasons when transmitting.  Mike mentioned non-
    schema-conforming systems that create instances out of a non-
    native format.  Another consideration with this kind of
    variability is that schema validation often performs a kind of
    in-memory transformation (e.g. adding default values for simple
    datatypes), which means that you can get different results if you
    operate in the presence vs. absence of a schema. (This is
    somewhat different from the post- schema validation infoset, or
    PSVI, which decorates the instance tree with type information
    gleaned from the schema.)

    We turned to discussing the use cases for using vs. not using
    default values in the schemas.  For example, in xCBL, they wanted
    to have a default for the agency value (e.g., UCC), but couldn't
    SOX didn't support default values.  Gunther pointed out that some
    defaults are going to be unique per community or set of trading
    partners.  Mike described how EDI has internal code lists (where
    the values are all in a single "symbol space") and external code
    lists, where you can have different sets of values for each
    space, so you need a tuple (symbol space plus value) to know all
    the necessary information.

    There are several ways to do "defaults": You can provide a real
    default value in the schema, you can do an implied value (where
    you just document the fact that certain values must be inferred
    by downstream processors), or you can create specific elements or
    attributes named after each symbol space that people can use if
    they want a value from that space.

    The precise concern is when a sender presumes that the schema
    will be available to provide additional information, but the
    recipient does not have access to the schema and thereby misses
    information. If we put default values in the schema and also
    specially document them as "application-level defaults", this
    will be sufficient for putting developers of these systems on
    notice.

    Mike suggested that business people will want all relevant data
    in the instance, as a convenience and legal matter.  Arofan
    disagreed, because there may be a lot of data that some parties
    care about that others don't want to see.  Can we assume that the
    schema always gets transmitted with an instance (or that the web
    server where it's available is always up)?

    Dave described how use cases can be nested, in effect, with more
    specific ones deriving from more general ones.

    ACTION: Arofan to talk to Pam Samuelson about the legal
    implications of default values supplied out-of-band.

    New terminology:

    Well-formedness checking:
    Basic XML 1.0 adherence.

    DTD validation:
    Adherence to an XML 1.0 DTD.

    Schema validation:
    Adherence to an XSD schema.

    schema processing:
    Schema validation checking plus provision of default values and
    provision of new infoset properties.

    Ad hoc schema processing:
    Doing partial schema processing, but not with official schema
    validator software; e.g., reading through schema to get the
    default values out of it.

    Instance constraint checking:
    Additional validation checking of an instance, beyond what XSD
    makes available, that relies only on constraints describable in
    terms of the instance and not additional business knowledge;
    e.g., checking co-occurrence constraints across elements and
    attributes. Such constraints might be able to be described in
    terms of Schematron.

    Application-level validation:
    Adherence to business requirements, such as valid account
    numbers.

    ACTION: Mark to add these terms and the others below to the
    document.

    We agreed to add a new field to our use cases: Actor.  We have a
    goal that it's possible to zip up the whole set of use cases and
    download them.

    We would be very surprised if real document creators were using
    Notepad.

    ACTION: Dave to create HTML template for people to use.

    ACTION: Arofan to create a new use case for instance constraint
    checking.

    ACTION: Mike to create a new use case for code list design.

    ACTION: Eve (with Dave's help) to create a set of new use cases
    for document creation.

    ACTION: Mike and Dale to add the Actor field to their use cases.


5. Positions

    5a. Customizations

    Arofan agreed to champion this.

    Arofan: New semantics that weren't in the CC model should
    expressed as added things.  But there should be a restriction
    that goes on first, in order to get CC-model items out where
    they're not needed. He advocates restricting at design time, and
    adding at run time; anything imported can't be restricted.

    New terminology:

    Context:
    A particular set of context driver values.

    Generic BIE:
    A semantic model that has a "zeroed" context.  We are assuming
    that it covers the requirements of 80% of business uses, and
    therefore is useful in that state.

    UBL schema module:
    A syntactic expression of a generic BIE.  We are assuming that
    UBL is just delivering generic versions and common contexts,
    *not* persistent contextualized schemas.

    Arofan advocates that we make available fairly sparse generic
    BIEs, but that they can have some of their content subtracted
    before getting new material added.  A particular context would
    control any subtraction (it could also be seen as positive
    selection) and addition.

    ACTION: Arofan to write the position paper for this for next
    Wednesday, using a small but complete example of needing
    subtraction/selection and addition.

    5b. Markup naming

    Mark is the champion for this.

    We discussed whether intuitive common-usage terms or dictionary
    terms should be used.

    Arofan advocated avoiding 11179-based hierarchical naming
    schemes. An example is <OrderTotalWithTaxPriceAmount> vs. a more
    generic, reusable <TotalOrderAmount>.  An XPath that shows the
    simple ancestry of the leaf element is just as revealing as the
    longer name.

    ACTION: Everyone to read the revised 11179 Part 5 and the
    snapshot of the Library Content SC's catalog to learn about
    naming issues (watch the wrapping in the URLs):
    http://www.oasis-open.org/committees/ubl/ndrsc/input/ISO-
    IEC-11179-5-E-2001-02-28.doc
    http://www.oasis-open.org/committees/ubl/ndrsc/input/UBL-BIE-
    catalog-20011112.xls

    ACTION: Everyone to comment on Section 5.2.1 (Markup Naming) by
    COB on Friday and continue discussion on the list.

    ACTION: Mark to recast the marking naming section as a position
    paper) and try to incorporate the list discussion for
    ratification next Wednesday.

6. Review and prioritize Mark's outline draft

    ACTION: Eve to add a link to the NDR SC page pointing to the
    xfront.com website and the XML.com dos and don'ts article.

    We discussed the idea of putting line numbers in, for ease of
    discussion.

    We agreed that position papers should be kept separate as long as
    the champion is actively editing it (even if the SC has begun
    discussing it).  Mark should maintain the outline, and extract
    his substantive section content and turn it into position papers.

    ACTION: Mark to do the above two things.

7. Next steps

    We hope to reach agreement on the markup naming position and the
    basics of the customization approach next time.  This will rely
    on lots of homework being done by everybody before that time!

8. Adjourn

    Adjourned at z:00.
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com