[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