[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