[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl] Minutes for UBL Naming and Design Rules meeting 14 November 2001
UBL TC people-- Here are the minutes for the latest NDR SC meeting. By our next meeting, we hope to have functional drafts of markup naming and customization guidelines. We have chosen these under the impression that they will be of highest priority to the Library Content folks; input from others is welcome. Some useful links: "Portal" for NDR SC work: http://www.oasis-open.org/committees/ubl/ndrsc/ ubl-ndrsc list archive: http://lists.oasis-open.org/archives/ubl-ndrsc/ Very early draft of outline for the document we will produce: http://www.oasis-open.org/committees/ubl/ndrsc/drafts/ndr-20011112.doc * * * 1. Roll call Quorum is 8, not 9; Kelly has dropped off. Quorum not reached as of x:06; we proceeded with an informal discussion. Bill Burcham YES (joined at x:15) Doug Bunting Dave Carlson YES Mark Crawford YES (joined at y:08; gave us quorum) John Dumay Matt Gertner Jack Gager Arofan Gregory YES Eduardo Gutentag Eve Maler YES Dale McKay YES Sue Probert Marion Royal YES (joined at y:11) Gunther Stuhec YES Mike Rawlins YES We briefly discussed changing our meeting times around in order to accommodate Australian participants (currently just John Dumay), but ultimately felt that we should keep to our original schedule at least through our first deliverable. 2. Acceptance of minutes of 7 November 2001 meeting http://lists.oasis-open.org/archives/ubl- ndrsc/200111/msg00026.html Deferred until we have quorum (but then forgot once we reached it :-). Will pick up next time. 3. Adoption of agenda Adopted. 4. Compile and rank use cases Mike sent out a set of use cases: http://lists.oasis-open.org/archives/ubl-ndrsc/200111/msg00063.html Dale sent out a use case: http://lists.oasis-open.org/archives/ubl-ndrsc/200111/msg00066.html The variability in many of Mike's use cases has to do with whether the schema is used to guide or check creation/use. Arofan pointed out that even people who use Notepad to create instances can check validity using a command line. Gunther noted that the SAP system allows you to avoid validity checks for performance reasons when transmitting. Mike mentioned non- schema-conforming systems that create instances out of a non- native format. Another consideration with this kind of variability is that schema validation often performs a kind of in-memory transformation (e.g. adding default values for simple datatypes), which means that you can get different results if you operate in the presence vs. absence of a schema. (This is somewhat different from the post- schema validation infoset, or PSVI, which decorates the instance tree with type information gleaned from the schema.) We turned to discussing the use cases for using vs. not using default values in the schemas. For example, in xCBL, they wanted to have a default for the agency value (e.g., UCC), but couldn't SOX didn't support default values. Gunther pointed out that some defaults are going to be unique per community or set of trading partners. Mike described how EDI has internal code lists (where the values are all in a single "symbol space") and external code lists, where you can have different sets of values for each space, so you need a tuple (symbol space plus value) to know all the necessary information. There are several ways to do "defaults": You can provide a real default value in the schema, you can do an implied value (where you just document the fact that certain values must be inferred by downstream processors), or you can create specific elements or attributes named after each symbol space that people can use if they want a value from that space. The precise concern is when a sender presumes that the schema will be available to provide additional information, but the recipient does not have access to the schema and thereby misses information. If we put default values in the schema and also specially document them as "application-level defaults", this will be sufficient for putting developers of these systems on notice. Mike suggested that business people will want all relevant data in the instance, as a convenience and legal matter. Arofan disagreed, because there may be a lot of data that some parties care about that others don't want to see. Can we assume that the schema always gets transmitted with an instance (or that the web server where it's available is always up)? Dave described how use cases can be nested, in effect, with more specific ones deriving from more general ones. ACTION: Arofan to talk to Pam Samuelson about the legal implications of default values supplied out-of-band. New terminology: Well-formedness checking: Basic XML 1.0 adherence. DTD validation: Adherence to an XML 1.0 DTD. Schema validation: Adherence to an XSD schema. schema processing: Schema validation checking plus provision of default values and provision of new infoset properties. Ad hoc schema processing: Doing partial schema processing, but not with official schema validator software; e.g., reading through schema to get the default values out of it. Instance constraint checking: Additional validation checking of an instance, beyond what XSD makes available, that relies only on constraints describable in terms of the instance and not additional business knowledge; e.g., checking co-occurrence constraints across elements and attributes. Such constraints might be able to be described in terms of Schematron. Application-level validation: Adherence to business requirements, such as valid account numbers. ACTION: Mark to add these terms and the others below to the document. We agreed to add a new field to our use cases: Actor. We have a goal that it's possible to zip up the whole set of use cases and download them. We would be very surprised if real document creators were using Notepad. ACTION: Dave to create HTML template for people to use. ACTION: Arofan to create a new use case for instance constraint checking. ACTION: Mike to create a new use case for code list design. ACTION: Eve (with Dave's help) to create a set of new use cases for document creation. ACTION: Mike and Dale to add the Actor field to their use cases. 5. Positions 5a. Customizations Arofan agreed to champion this. Arofan: New semantics that weren't in the CC model should expressed as added things. But there should be a restriction that goes on first, in order to get CC-model items out where they're not needed. He advocates restricting at design time, and adding at run time; anything imported can't be restricted. New terminology: Context: A particular set of context driver values. Generic BIE: A semantic model that has a "zeroed" context. We are assuming that it covers the requirements of 80% of business uses, and therefore is useful in that state. UBL schema module: A syntactic expression of a generic BIE. We are assuming that UBL is just delivering generic versions and common contexts, *not* persistent contextualized schemas. Arofan advocates that we make available fairly sparse generic BIEs, but that they can have some of their content subtracted before getting new material added. A particular context would control any subtraction (it could also be seen as positive selection) and addition. ACTION: Arofan to write the position paper for this for next Wednesday, using a small but complete example of needing subtraction/selection and addition. 5b. Markup naming Mark is the champion for this. We discussed whether intuitive common-usage terms or dictionary terms should be used. Arofan advocated avoiding 11179-based hierarchical naming schemes. An example is <OrderTotalWithTaxPriceAmount> vs. a more generic, reusable <TotalOrderAmount>. An XPath that shows the simple ancestry of the leaf element is just as revealing as the longer name. ACTION: Everyone to read the revised 11179 Part 5 and the snapshot of the Library Content SC's catalog to learn about naming issues (watch the wrapping in the URLs): http://www.oasis-open.org/committees/ubl/ndrsc/input/ISO- IEC-11179-5-E-2001-02-28.doc http://www.oasis-open.org/committees/ubl/ndrsc/input/UBL-BIE- catalog-20011112.xls ACTION: Everyone to comment on Section 5.2.1 (Markup Naming) by COB on Friday and continue discussion on the list. ACTION: Mark to recast the marking naming section as a position paper) and try to incorporate the list discussion for ratification next Wednesday. 6. Review and prioritize Mark's outline draft ACTION: Eve to add a link to the NDR SC page pointing to the xfront.com website and the XML.com dos and don'ts article. We discussed the idea of putting line numbers in, for ease of discussion. We agreed that position papers should be kept separate as long as the champion is actively editing it (even if the SC has begun discussing it). Mark should maintain the outline, and extract his substantive section content and turn it into position papers. ACTION: Mark to do the above two things. 7. Next steps We hope to reach agreement on the markup naming position and the basics of the customization approach next time. This will rely on lots of homework being done by everybody before that time! 8. Adjourn Adjourned at z:00. -- 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