[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