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 1-4 October 2002 UBL NDR SC meeting


Minutes for 1-4 October 2002 UBL NDR SC meeting

=====================================================================
*Summary of action items

Paul:
- Do an analysis of the "XML Constructs" chapter to figure out the
   XML/XSD-specificity question at a finer granularity, and make any
   editorial suggestions based on the analysis.

Mavis:
- Turn the free normative text in the NDR document into isolated,
   numbered rules.

Mavis and Bill:
- Get together offline to move the appropriate modnamver paper content
   into the NDR document.

Bill:
- Revise the NDR metamodel to reflect the CCTS V1.85 metamodel,
   including giving explanations of how the naming works between the
   two systems.  This needs to include documentation of the rules
   already being applied in the spreadsheet formulae.

Eve:
- Propose some declarative text describing XML's minimum character
   set/character encoding expectations and saying that UBL has the same
   minimum mandatory-to-implement expectations.
- Compile a list of the supplementary compenents and their definitions
   on a per-CCT basis.
- Ask the Sun XML community to analyze the seriousness of the fragment
   processing problem with local elements.
- Write up her concern about the use case of using UBL components
   without change, while having software that's not type- aware.

Jessica:
- Send her flow diagram of hiding and exposing namespaces to the list
   for inclusion in the NDR document.

=====================================================================
*1 October 2002

=======================================
*Roll call (quorum is 8)

     * Bill Burcham         YES
     * Mavis Cournane       YES
     * Mark Crawford        YES
     * Fabrice Desré        YES
     * Arofan Gregory       YES
     * Jessica Glace        YES
     * Michael Grimley      YES
     * Eduardo Gutentag     YES
     * Eve Maler            YES
     * Sue Probert          YES
     * Lisa Seaburg         YES
     * Gunther Stuhec       YES
     * Paul Thorpe          YES
     * Kris Ketels          no

    Observers

     * The rest of the F2F attendees

=======================================
*Deliverables and schedule - joint

(see Lisa's minutes)

=======================================
*Plans for joint work - joint

Wednesday afternoon:
- Compare proposals for deliverables and schedule
- Show and tell

Thursday afternoon:
- Containership
- Show and tell

Friday afternoon:
- Show and tell

=======================================
*Acceptance of minutes of previous meeting - NDR only

    25 September 2002
    http://lists.oasis-open.org/archives/ubl-ndrsc/200209/msg00046.html

Accepted.

=======================================
*Proposals for deliverables and schedule - NDR only

Fodder for our NDR deliverable set (see also FOR LC SC notes
throughout):

- Intro and roadmap to NDR deliverables (or NDR portion of a UBL-wide
   intro and roadmap)

- Rules documents
   - (Separate out rules documents by audience)
   - Naming and design rules (Mavis and Lisa)
     - (Which position papers should be in appendices?)
     - (Separate out XML-specific vs. XSD-specific rules)
     - (Cover rules for modnamver, local vs. global, dates/times,
       containership, facets, embedded documentation...)
   - Code list rules (Eve)
     - Code list module template
   - Content identifier rules? (Gunther)

- Position papers (non-normative)
   - Dates and times position paper (Gunther)
   - Local vs. global position paper (Fabrice)
   - Content identifier position paper? (Gunther)
   - (Do we need an additional NDR-based containership paper?)

- White papers
   - Code list white paper (Eve)
   - (Additional white papers?)

- CCT module
   - (But the NDR SC can't remain its maintainer)

- ubl-dev mailing list

- Expanded portal with links to implementations, customizations, etc.

We want to make sure these are covered by someone, to the extent that
they care, but we don't want to own this:

- Alternative schema representations and accompanying explanations
   - ASN.1 (Paul)
   - RELAX NG (Eduardo)
   - DTD (anyone?)
   - UML (Dave Carlson)

=======================================
*Planning our agenda for the rest of the week - NDR only

These are "must do's" this week:

    A Local vs. global
    A Code lists
    A CCT module work
    A Containership
    A (was B) Referencing strategies: don't need to solve; "wake up"
    A Reorg and revise NDR doc

Wednesday
- NDR doc
- CCT module work
- Local vs. global
- (Context methodology)
- (Evening: Tools and techniques)

Thursday
- NDR doc
- Containership
- Referencing

Friday
- NDR doc
- Code lists

=====================================================================
*2 October 2002

=======================================
*Roll call (quorum is 8)

     * Bill Burcham         YES
     * Mavis Cournane       YES
     * Mark Crawford        YES
     * Fabrice Desré        YES
     * Arofan Gregory       YES
     * Jessica Glace        YES
     * Michael Grimley      YES
     * Eduardo Gutentag     YES
     * Eve Maler            YES
     * Sue Probert          no
     * Lisa Seaburg         no
     * Gunther Stuhec       YES
     * Paul Thorpe          YES
     * Kris Ketels          no

=======================================
*Discussion of context methodology - NDR only

Motion:

"We recommend that the Phase 1 context methodology work be rolled into
the NDR work and treated as an A-priority item for the rest of the
calendar year.  Our rationale is that the two subjects and their
memberships overlap significantly and that this combination will
require fewer resources, giving us a chance to actually complete the
work."

Approved unanimously.

=======================================
*NDR document review - NDR only

We worked through the document looking for certain features:

- The occurrence of "SHOULD" instructions (there are several; should
we work to avoid them?)

- Whether each section is only XML-specific or actually XSD-specific

ACTION: Paul to do an analysis of the "XML Constructs" chapter to
figure out the XML/XSD-specificity question at a finer granularity,
and make any editorial suggestions based on the analysis.

ACTION: Mavis to turn the free normative text in the NDR document into
isolated, numbered rules.

We discussed problems with our use of "fully qualified path (FQP)" --
we haven't said what it actually means, and it *doesn't* merely mean
the BIE name that's already present in the spreadsheet for each row.

Example (hypothetical, not necessarily accurate according to 0pt65; we
need to find an accurate example): The Party.Identifier.Identifier has
a definition of "The identifier for a party".  But as soon as an order
has a property of a seller party (Order.SellerParty.Details), the ID
within the seller party structure needs its specific processing
expectations to be documented. This documentation has to be associated
with the element *within its parent element*, not merely within the
parent type that is its object class.  (Does this particular ID have
to be a DUNS number, for example?)

The current documentation that we're prepared to generate only covers
the BIE entries.  We believe that the FQP documentation can be sparse
-- that is, not all //parent-element/target-element combinations need
special documentation beyond what is already in the spreadsheet.

FOR LC SC: Discuss the FQP issue related to packaging and substance.

FOR LC SC: What happened to the "reusable types" (common aggregate
types) schema module?

ACTION: Bill and Mavis to get together offline to move the appropriate
modnamver paper content into the NDR document.

ACTION: Eve to propose some declarative text describing XML's minimum
character set/character encoding expectations and saying that UBL has
the same minimum mandatory-to-implement expectations.

When we next discuss the NDR document, we need to do the following
things:

- Segregating information by audience (internal vs. external)
- Eve's list of items taken from the minutes
- Finding homes for all the position paper information

=======================================
*CCT module work - NDR only

In V1.85, CCTs and primary RTs have a one-to-one relationship.

We discussed the new concept of a secondary RT, which functions as a
semantic (but not structural) specialization of a primary RT -- sort
of like an alias.  We think that our CCT module should reflect
secondary RTs as restrictions of their primary RTs.  In some cases
these restrictions will be trivial (i.e., no structural changes), but
we think that in other cases non- trivial changes would be needed.

So according to our datatype-naming rules for XSD, we'll have (for
example) a TextType and a NameType, where the latter is a secondary RT
-- and not strictly a type in CCTS terms.

We then discussed the new changes to the supplementary components on
the CCTs.  These have been much enhanced.  In yesterday's meeting we
had the impression that each set of supplementary components is now "a
la carte" -- a selection from which you can choose -- but we found it
difficult to support this with text from the CCTS document.

We concluded that we were right: Our reading of V1.85 (the storage CCT
metamodel in Section 7.1) is that every piece of business information
associated with a particular CCT always has at least one supplementary
component value supplied, but that we have freedom in both (a) leaving
off values for unneeded supplementary components in each case and (b)
adding new CCT metadata according to our own requirements (while
submitting these to UN/CEFACT for consideration).

We then discussed the new guidelines for distinguishing between codes
and identifiers, and names and text strings.  For example, Code List.
Agency. Identifier defaults to codes from a particular code list, but
it has the "Identifier" RT because an agency is a real-world object.
Gunther added his own interpretation of the code/identifier
distinction, which has to do with whether the values are a relatively
static set or a relatively dynamic one (still a continuum).

This is how our CCT XSD type hierarchy will look:

AmountType
BinaryObjectType
   GraphicType
   PictureType
   SoundType
   VideoType
CodeType
DateTimeType
   DateType
   TimeType
IdentifierType
IndicatorType
MeasureType
NumericType?
   ValueType
   RateType
   PercentType
QuantityType
TextType
   NameType

Our task is to:

- Identify the supplementary components from the CCTS list that we
   want
- Identify any additional supplementary components that we think are
   missing
- Provide a definition for each supplementary component that reflects
   our interpretation of its purpose, ensuring that all cases of
   "nestedness" are sufficiently taken care of (through defaults or
   through additional components)
- Understand and define any naming rules and requirements for the
   supplementary component attributes, if the existing rules don't
   suffice
- Document the cardinality (optionality) requirements for our chosen
   supplementary components
- Get LC SC feedback on our efforts
- Implement the module and see how it works

We see a problem with NumericType.  Because XSD Part 2 doesn't
have a built-in "numeric" simple datatype that corresponds to the
general category of "numbers" the same way that Numeric. Type does, we
don't have an easy way to define a *single* type that forms the base
for all of the CCT-based numeric types.  We're leaning towards not
defining CCTS-based equivalents for all of the number-related built-in
types.

FOR LC SC: We think there needs to be a new column for "numeric
format" so that we know what datatype to bind to the relevant element.

Here are some fledgling design principles around our CCT->XSD mapping:

1. If there's a perfectly serviceable XSD built-in type, use it
    instead of defining a CCTS equivalent.

2. If a default code list has been identified by CCTS, mandate it.

It was suggested that we reconsider our attributes-only-for-
supplementary-components decision.  We will think about that when we
get down to cases.

ACTION: Eve to compile a list of the supplementary compenents and
their definitions on a per-CCT basis.

=======================================
*Local vs. global - NDR only

This is a first cut of our analysis of positives and negatives:

Local element characteristics:
+ Vocabulary can have multiple elements with same name

Global element characteristics:
+ Fragment processing is uncomplicated
+ Can be reused directly
- All elements must have unique names

Qualified element characteristics:
+ Customizers can safely define unqualified elements
. Instances can look clean with defaulting

Unqualified element characteristics:
+ *Very* clean, simple instances
- Customizers can't safely define unqualified elements
- Unusual design choice; in most vocabularies all elems are qualified

=======================================
*Packaging discussion - joint

Following is a modified version of the original that we developed on
the first day, including comments received in this joint session and
eliding NDR-specific notes:

- NDR portion of a UBL-wide intro and roadmap (with the whole owned by
   Tim/LC SC)

- Rules documents
   - Naming and design rules (Mavis and Lisa)
   - Code list rules (Eve)
     - Code list module template
   - Content identifier rules? (Gunther)

- Position papers (non-normative)
   - Dates and times position paper (Gunther)
   - Local vs. global position paper (Fabrice)
   - Content identifer position paper? (Gunther)

- White papers
   - Code list white paper (Eve)

- CCT module

- ubl-dev mailing list (Jon)

- Expanded portal with links to implementations, customizations, etc.

We want to make sure these are covered by someone, to the extent that
they care, but we don't want to own this:

- Alternative schema representations and accompanying explanations
   - ASN.1 (Paul)
   - RELAX NG (Eduardo)
   - DTD (Arofan)
   - UML (Dave Carlson)

- Context drivers

Other issues we identified:

- What happened to the "reusable types" (common aggregate types)
   schema module?  0pt65 happened not to include it because of sudden
   changes in the perl script, but the intent is to add it.  this led
   to a discussion of the difficulties in determining what types are
   truly "reusable" (and whether there are any non-reusable types).

- An important documentation deliverable is missing: the "FQP"
   definitions (a sparse matrix of additional definitions; see the
   discussion above for more detail).  How can it be created?  The LC
   SC is identifying some needs for describing these additional
   business rules, but it currently isn't placing a priority on
   capturing these. We know this information is important for
   developers to know in order to create interoperable applications.
   There seems to be considerable value in figuring out how to capture
   this now, even if it's too sparse at first; that way, trading
   communities can use this method for indicating their own specific
   business rules.

We're hoping that the message assembly methodology artifact will
provide a place for this information.  The TT SC is meeting this
evening and will talk about ways to automate this.

=======================================
*Review of NDR work in this F2F so far - joint

Done.

=====================================================================
*3 October 2002

=======================================
*Roll call (quorum is 8)

     * Bill Burcham         YES
     * Mavis Cournane       YES
     * Mark Crawford        YES
     * Fabrice Desré        YES
     * Arofan Gregory       YES
     * Jessica Glace        YES
     * Michael Grimley      YES
     * Eduardo Gutentag     YES
     * Eve Maler            YES
     * Sue Probert          no
     * Lisa Seaburg         YES (partial)
     * Gunther Stuhec       YES
     * Paul Thorpe          YES
     * Kris Ketels          no

=======================================
*NDR document review - NDR only

We worked through the NDR document, making notes on the following:

- Eve's list of items taken from the minutes
- Finding homes for all the position paper information

ACTION: Bill to revise the NDR metamodel to reflect the CCTS V1.85
metamodel, including giving explanations of how the naming works
between the two systems.  This needs to include documentation of the
rules already being applied in the spreadsheet formulae.

FOR LC SC: Their modeling/methodology writeups need to cover advice on
how to choose good tripartite names.  (We will cover how these parts
get translated into the names of XML constructs.)

FOR LC SC: Is it a problem if association BIEs have "Identifier" (or
"ID") as part of their name, given that "Identifier" is known as a
CCT/RT and -- according to our rules -- is therefore an XML leaf
element?

We still have this task to do:

- Segregating information by audience (internal vs. external)

=======================================
*Containership - NDR only

What are the ways in which the Header and Summary containers are
currently used?

. Human understanding -- chunking principles
. Collecting defaults that apply throughout the message (metadata)
. Presentation of material that is usually shown at the "top" or
   "bottom"
. Efficiency of transmission over the wire (in traditional EDI)

What are the technical characteristics of containers in general?

+ Extensive container usage gives the ability to present information
   to developers in small, understandable chunks (IE allows you to
   collapse elements you're not looking at)

+ Referenceability (can have an ID, is easily addressable) -- the
   normalization methodology puts a premium on identifying primary
   keys of entities, which helps this goal

+ Point of extension (only types can be extended)

+ Reusability (e.g., reproducing the content of elements repeatedly)

- Handling containers is inefficient in some systems

What are the technical characteristics of presentational containers?

+ Can help performance of some systems (e.g. mapping to traditional
   EDI)

- Can hinder mapping to systems that don't have true containers

+ Make some processing possible (where it wasn't before) on certain
   legacy systems

- In modern systems, it can get in the way (the "pass-through"
   semantics idea)

(We note that "orthogonality" is the same thing as "functional
independency".)

We discussed whether OO "likes" containers or "dislikes" them.  At a
high level, OO (as evidenced by UML class diagrams) seems to depend
entirely on containers, since we can see objects as containers -- and
in fact this is what our design rules result in. However, at a low
(implementation) level, most serializations of objects don't use a
hierarchical representation.

One question we haven't discussed in depth is advice on when to use
association by containment (vs. association through more relational
means).  This is at the heart of the notion of "assembly" -- different
business process priorities result in different containment
relationships.  For example, for orders, we decided that the "order"
is primary and thus is the root element.  Each sub-root of it reflects
a further prioritization of purpose.  A different order would reflect
a different process.  Currently we're (really LC SC is) designing all
these assemblies in static fashion, but eventually maybe there will be
a dynamic method.

We need to wait to see the results of the LC SC normalizing process to
discover whether the new containers (or lack thereof) seem
problematic.

=======================================
*Local vs. global - NDR only

On a scale of -10 to +10:

Local element characteristics: total points -10
  0 We don't need to change anything
  0 Vocabulary has unique element declarations for each unique BIE (as
    opposed to reused and referenced global elements)
  0 Vocabulary can have multiple elements with same name with different
    content models (as required by the "Rules Governing Elements of the
    Same Name and Their Respective Types" section)
-2 In actual usage, there is a risk of confusion
-3 Fragment processing requires expensive pre-processing to add
    xsi:type (or other necessary context) [controversial]
-5 Types are required to be re-bound to foreign elements in attempts
    to reuse individual components of the UBL Library (which has
    negative consequences for reuse of software) [controversial]

Global element characteristics: total points +6
+3 Fragment processing is uncomplicated [controversial]
+5 Elements be reused directly (which has positive consequences for
    reuse of software) [controversial]
+5 Typical design choice (but by no means universal)
  0 All elements in the vocabulary must have unique names
-3 It is expensive to change at this point
-4 Going forward, there is a cost to ensuring that each new element
    name is unique

Qualified element characteristics: total points 0
+2 Customizers can safely define unqualified elements
  0 Instances can look clean with defaulting
-2 Writing XSLT stylesheets with namespace support requires more
    understanding
  0 It is expensive to change at this point

Unqualified element characteristics: total points -8?
+2 *Very* clean, simple instances (the xmlns= default doesn't need to
    appear at the top)
0  We don't need to change anything
-2 With a null namespace, can't use the namespace name to indicate
    version changes in the vocabulary, which can silently change the
    behavior of software (but our qualified root element gives many of
    the benefits of a non-null namespace)
-7 Customizers can't safely (routinely, without doublechecking) define
    unqualified elements; there may be name clashes; if an importing
    schema is tempted to qualify by using
    elementFormDefault="qualified", there is some risk that our
    elements will change their nature
-1 Unusual design choice; in most vocabularies all elems are qualified
-? Elements are not directly available for reuse (which has negative
    consequences for reuse of software, but any software for elements
    in reused UBL types will still work)

Named types:
+ Makes derivation possible

Anonymous types: REJECT
- No possibility of derivation

We discussed the problem of "type-awareness" in software.  There are
some users who can take advantage of the PSVI (e.g., with data binding
-- schema compilation).  But there are other users who cannot (e.g.,
traditional EDI setups and XPath 1.0 users).  Can we walk the line of
providing type information to one audience but not requiring type-
awareness from the other?

ACTION: Eve to ask the Sun XML community to analyze the seriousness of
the fragment processing problem with local elements.

ACTION: Jessica to send her flow diagram of hiding and exposing
namespaces to the list for inclusion in the NDR document.

Bill discovered that elementFormDefault="qualified" on a schema that
imports UBL will suddenly qualify all the formerly unqualified local
elements, but since Roger Costello says this is wrong, we don't know
whom to believe.  Bill used XML Spy to do his test.  If the importing
schema setting overrides the imported schema setting, formerly valid
instance fragments would potentially become invalid, creation software
would break, and processing software would break.

The use case of reusing UBL components as-is to make new messages, vs.
the use case of deriving a new trading-community-specific derivation
of an existing UBL message, would possibly benefit from reusable
elements in the case where software is not type-aware.  The actual
element can be reused, rather than reusing just its type.  If the
element (rather than the type) is strongly needed by software, a
parent type could be reused and the contained UBL element would come
along with it, but then you get the unneeded baggage of the rest of
the parent type's content model.

ACTION: Eve to write up her concern about the use case of using UBL
components without change, while having software that's not type-
aware.

Our points system suggests that we should switch to global qualified
elements, but we still need to finish discussing this and get the
remaining input from the outstanding action items.

=======================================
*Review of NDR work in this F2F so far - joint

Is it a problem if association BIEs have "Identifier" (or "ID") as
part of their name, given that "Identifier" is known as a CCT/RT and
-- according to our rules -- is therefore an XML leaf element?  Their
feeling is that this will never be done.

=====================================================================
*4 October 2002

=======================================
*Roll call (quorum is 8)

     * Bill Burcham         YES
     * Mavis Cournane       YES
     * Mark Crawford        YES
     * Fabrice Desré        YES
     * Arofan Gregory       no
     * Jessica Glace        YES
     * Michael Grimley      YES
     * Eduardo Gutentag     YES
     * Eve Maler            YES
     * Sue Probert          no
     * Lisa Seaburg         no
     * Gunther Stuhec       YES
     * Paul Thorpe          no
     * Kris Ketels          no

=======================================
*Publication schedule and NDR document review - NDR only

We agreed to publish weekly internal updates with change bars for our
own review purposes, and to advertise public-review snapshots on or
about October 16 and November 13.

We will not meet on October 9.  Instead, everyone will work hard on
their action items so that an internal-review version can be put out
that week.  Once it is sent out, it will not change except by
agreement of the SC in the October 16 meeting.

We will meet on:

October 16
October 23 (Michael G., Jessica, Mark regrets)
October 30 (Eve regrets; Mark will cover)
November 6
November 13

before the F2F on November 18-21.

=======================================
*Code lists - NDR only

Eve gave an update on the code list rules status and the existence of
the ebXML Registry Information Model classification schema vocabulary.

=======================================
*Identifiers presentation - NDR only

Gunther presented requirements for globally unique identification,
with an emphasis on implementation constraints within SAP.  (See
slides sent out under separate cover.)

=======================================
*Local vs. global - NDR only

See the discussion in yesterday's notes, which reflects notes from
both yesterday and today.

=======================================
*Status update - NDR only (compiled after the fact)

    A Issues appearing in the NDR document
    A Local vs. global NEEDS FINAL RESOLUTION
    A Code lists NEEDS NEW DRAFT
    A CCT module work IN PROGRESS; BREAK DOWN INTO SMALLER PIECES?
    A Containership NEEDS FINAL RESOLUTION
    B Referencing strategies NOT DONE
    B Naming rules wrt CCTS V1.85 DONE
    C Facet outreach CANCEL?
    C Modnamver NEEDS TO BE MOVED TO NDR DOC
    C Embedded documentation NEEDS TO BE MOVED TO NDR DOC
    C ASN.1 schema DONE
    C Updating guiding principles IN PROGRESS
    C Wildcards NOT DONE
    C Nillability NOT DONE
    C Instance constraints LISA TO WORK ON THIS?

Are there any new items we need to add?  Should we catalog all of the
"flesh out" notes in the NDR document so that we can prioritize and
then tackle them?


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



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


Powered by eList eXpress LLC