MHonArc v2.5.2 -->
ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [ubl-ndrsc] New recommendations/comments from the NDR SC
The raw minutes of the NDR and CM SC meetings last week (some of which
cover joint sessions with the LC SC) can be found at:
http://lists.oasis-open.org/archives/ubl-ndrsc/200203/msg00028.html
I was tasked to let the LC SC know about NDR SC recommendations that
we officially approved last week:
Native Context:
Ron Schuldt has written up a paper making his case for UDEF attributes
on UBL constructs. The paper can be found at the NDR portal,
http://www.oasis-open.org/committees/ubl/ndrsc/. (The paper expects a
disposition from the LC SC, though most of the discussion we've had on
the matter so far has been in the NDR SC.) After discussion, the NDR
SC approved the following motion: "Refer Ron's proposal to the LC SC
with a recommendation that it not be adopted as part of core UBL but
rather considered as a possible extension that external
parties could create."
Number of Document Types:
As we mentioned in our final joint session last Friday, the NDR SC
supports a bias towards creating more document types ("instance
roots", "message types", "top-level elements") for the semantic
clarity and validation power it brings. We approved the following
motion: "Ratify the one-doctype-per-transmission principle as
stated in the UBL Planning report and the modnamver paper."
Comments on the 0.64 Distribution:
Following are the comments we've collected to date (we know there will
be more) on the 0.64 distribution made available last week.
Reviewer: OASIS UBL NDR SC
Contact details: ubl-ndrsc@lists.oasis-open.org
Date: 26 March 2002
Artifact/version reviewed: 0.64 spreadsheet
========
UBL UID: General comment.
Comment: The spreadsheet is missing System
Constraints Context and Supporting Role Context.
Proposal: Add these columns.
References: None.
========
UBL UID: General comment.
Comment: We note that there is no capturing of precision (for numeric
formats) and other similar constraints, such as string lengths.
This will need to be captured at a later date.
Proposal: Figure out a methodology for capturing this information and
then go through the structures capturing it.
References: None.
========
UBL UID: General comment.
Comment: We think we'll need a rule eventually about how relationships
(extra-hierarchical) get encoded in XML. E.g., ID/IDREF, URI,
application-specific IDs, linkbases, etc. We wonder if the LCSC is
sufficiently considering its requirements about such relationships.
Proposal: Looking for such relationships should probably be in the
methodology somewhere. The following template of information that
could be collected about each link is adapted from "Developing SGML DTDs":
- Type of relationship/meaning expressed
- What source(s) and target(s) are being associated
- Directionality (e.g., is it a two-way relationship?)
- How the link gets used in processing
This is probably enough information for the NDR SC to get started
recommending one or more linking strategies in the actual schema modules.
References: Developing SGML DTDs, ISBN 0-13-309881-8
========
UBL UID: General comment.
Comment: Do not use specific words that have different meanings in
different industries (like check-in/check-out, which are the opposite
in hotel and rental cars); instead, go for general terms (e.g.
period-start, period-end, etc.)
Proposal: See above.
References: None.
========
UBL UID: UBL000002 (occurs other places as well)
Comment: UBL Name should be "BuyerID" because you're supposed to fold
the property term into the representation term when they're similar,
and you're supposed to truncate Identifier to ID.
Proposal: Change name here to "BuyerID" and check other similar cases.
References: None.
========
UBL UID: UBL000017
Comment: Is there a need to provide rules for constructing models that
allow for either a small-grained structure (address postbox ID
etc.) and a large-grained structure (address line 1 etc.)?
Proposal: Consider the option of allowing more "blob"-like addresses
that call out only a few specific pieces of information. This could
possibly be done as a "choice group" beneath the main address
structure, so that both options are always available when an address
is being supplied. However, if one of the options needs to be removed
in certain contexts, then it is more appropriate to make two object
classes for different kinds of addresses and pushing the optionality
"up" a level. (We are happy to discuss this kind of modeling further
with the LC SC.)
References: None.
========
UBL UID: UBL000017 (occurs other places as well)
Comment: The structure seems unusually flat by XML, OO, and database
standards. While we're not against the use of sequences, we suspect
that developers may find it more useful to have collections of
elements that are "rolled up" into container elements at an
intermediate level (for example, rows 30-31 for country sub-
entities). The classic chunking standard for human memory is 7 +/- 2,
and standard operating procedure for software developers and database
designers is to use this standard.
Proposal: Consider intermediate containership for addresses, and
possibly other structures with long flat sequences.
References: None.
========
UBL UID: UBL000017 (occurs other places as well)
Comment: We note that there's a lot of optionality of elements. For
example, there's nothing required in Address. Are there
interoperability consequences to this? If the context methodology is
sufficient, is it better to allow optional elements to be made
required or better to allow removal of elements? Would intermediate
containers help this situation at all (e.g., you can make the
container optional and the contents required)? How is the "sweet spot"
determined on this? As another example, we know that there will be
other kinds of things that we want to consider line items, but each
kind will have a different combination/cardinality of contents. We
want to have a rule that the structures have the maximum number of
required contents, and where splitting the structure into multiples
will help, it should generally be done.
Example: Line items contain at least quantity (1), part number (2),
and description (3). In certain stages of the process, they also
contain price information (4), tax information (5), and shipping
information (6). So you have really four kinds of line item: order,
invoice, shipping, and catalog. These should be considered different
rows.
Proposal: Consider intermediate containership in order to require
information that is truly required, assisting interoperability. Also,
consider splitting some structures into multiples for the same benefits.
References: None.
========
UBL UID: UBL000345
Comment: The choice of property term seems to obfuscate the desired
semantic here. This is supposed to identify the order from the
buyer's perspective; something like "Buyer's Order ID" would convey
this better, though possessives in English are suspect for tag naming.
Proposal: Consider a different name here.
References: None.
========
UBL UID: UBL000338 (as an example)
Comment: The LineItem content in the Order model, and likely many
(most? all?) other things that have 0..n or 1..n cardinality, could
usefully be grouped in a containing structure (the xCBL ListOf...
design pattern). For some (all?) 0..n things, it might be desirable
to make the container 0..1 and the contents 1..n.
Proposal: Consider adding a "list of" notion in order to capture
series of like things and strengthen validation.
References: None.
Respectfully submitted,
Eve Maler
for the NDR SC
--
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