[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Agenda for 19 March 2003
Please use the following dial-in
information:
Toll-free (from the U.S.): +1 888 422-7116 Int'l Access/Caller Paid Dial In Number: +1 608 250-1828 PARTICIPANT CODE: 398769 1. Roll Call and Welcome from the chair (Lisa), assignment of co-chair to take minutes. 2. Acceptance of minutes from previous two meetings I couldn't find a way to get to the archive, so I
am attaching a text version of the minutes from last week.
3. Adoption of agenda/schedule planning 4. Kavi Issues, Discussion of member lists
(Lisa) -
5. Review NDR release schedule (Mark) 6. Review of Project List: A+ NDR document update (in progress)
A Code list rules and schema template - (in progress, discussed and formulated more rules in this call) A Embedded documentation (in progress) A Local vs. global elements - (rediscussion closed on March 17th. Discussed further in this call) A Namespace rules (getting into NDR main doc) A Versioning rules (getting into NDR main doc) - in progress A Context Methodology (only comments from Mark so far, to be discussed further next week) B Common Core Components documentation - (in progress, Gunther is speaking directly with reviewers of this in San Diego this week. Will have a call with Mavis next week to put it all together) B Containership (to be put first on the agenda for next week) 7. Review of Sub Committees:
Library Content SC (Sue),
LCSC QA Team, working on comments (Sue/Anne)
- LCSC
Schedule is attached, please review, we will discuss.
- All
comments to date have been assigned to QA Team owners.
- NDR QA Team
update, will they make the Friday Call?
Tools and Techniques
(Gunther)
Context Methodology
(Eduardo)
8. Other Business?
9. Adjourn
++++++++++++++++++++++++++++++++++++++++++++++++++++ Lisa Seaburg AEON LLC Website: http://www.aeon-llc.com/ Email: lseaburg@aeon-llc.com Alternative Email: xcblgeek@yahoo.com Phone: 662-562-7676 Cellphone: 662-501-7676 "Remember that great love and great achievements
involve great
risk."
++++++++++++++++++++++++++++++++++++++++++++++++++++ |
From: "Mavis Cournane" <mavis.cournane@cognitran.com> To: "UBL NDR" <ubl-ndrsc@lists.oasis-open.org> Subject: [ubl-ndrsc] Minutes: NDR SC 12 March 2003 Date: Wednesday, March 12, 2003 12:49 PM Please find the minutes of this week's NDR call below. Regards Mavis 1. Roll Call and Welcome from the chair (Mavis), assignment of co-chair to take minutes. Mavis Cournane Lisa Seaburg Mark Crawford (AWOL) Gunther Stuhec Sue Probert (regrets) Fabrice Desré (regrets) Dan Vint (regrets) Arofan Gregory Jessica Glace Mike Grimley Paul Thorpe (AWOL) Matt Gertner (x:45) Eve Maler Eduardo Gutentag Kris Ketels (y:15) Jim Wilson (AWOL) Ann Hendry Bill Burcham (y:30) 2. Acceptance of minutes from previous two meetings http://lists.oasis-open.org/archives/ubl-ndrsc/200302/msg00093.html http://lists.oasis-open.org/archives/ubl-ndrsc/200303/msg00018.html Minutes accepted, quorum achieved X:10 3. Adoption of agenda/schedule planning We moved Context Methodology and Polymorphism up the agenda to facilitate Matt Gertner who can attend the first 45mins of the concall. 4. Review priorities and assignment of work items (Mavis/Lisa/Mark) A+ NDR document update (in progress) A Code list rules and schema template - (in progress, discussed and formulated more rules in this call) A Embedded documentation (in progress) A Local vs. global elements - (rediscussion in progress until March 17th. Discussed further in this call) A Namespace rules (getting into NDR main doc) A Versioning rules (getting into NDR main doc) - in progress A Context Methodology (only comments from Mark so far, to be discussed further next week) B Common Core Components documentation - (in progress, Gunther is speaking directly with reviewers of this in San Diego this week. Will have a call with Mavis next week to put it all together) B Containership (to be put first on the agenda for next week) 5. Review NDR release schedule (Mark) Deferred 6. Review Code list status Eve wants to comment on four items (A) Question of generic code type vs creation of UBL of dummy models for orphaned code lists. E: believes G already ahas generic code type which is great and used for all codes so far. Since we have these design patters, code list is proprietary etc, there is a design pattern for unknown. In that case there is a pttern of attributes you would supply and this is in the generic code type so far. It is the perfect way to go forward for now. A: agrees. If we create dummies we run in to the hassle of maintiang code lists until someone replaces it with something official. Rule for NDR document. WE are talking aobut UBL Library in this instance. PROPOSED RULE: Where a code list producer has not created a conforming code list schema module, the UBL library must bind the code property to the generic code type found in the CCT module. Accepted rule. (B) CCTS defines code as string of characters. However, there is nothing in our rules that requires it be a string of characters, it could be xml. We have CodeContentType which we said is simple. Does CCTS restrict us to having to make this simple? The CCTS definition of code ends up saying it is a string of characters. Do we relax the requirement that it be a simple type? The advantage of having subelements is we don't need special parser for the value of the code. E: we are neutral on the actual code values. If we were to take a stance in this area it would be the first time. You can do hierarchies elements within elements. The hierarchy in the taxononmy is highlighted by a series of fields K: What is happening, you are not using XML as mark up lanaguages. You are implying a number of things. E: we currently don't standardize, A: if we require them to use XML we are making their codelists invalid. E: right now it prevents it. Only reaons to prevent it is because of CCTS. E: Codes are at a leaf level. As XML matures we could let it be a branch level. A: what about the case of UN SPSC maintained by two organizations. It is a deeply hierarchical code lists describing products and services talking about what indsutry you are in. This could be expressed by a leaf node or as an entire string that gives you values at each level of the hierarchy. Some poeple will have a vast enumeration, others will model it in XML. All our rules break dow if we allow substructures here. G: a string is useful for our first version. K: some of the finance code structures is also a code list that contains a hierarchy. E; This is very common to have codelists loaded with subfields. It is up to the codelist producers decide whether to use XML or not. Let's not dictate it. A: as a member of CCTS it was never discussed. The intent of making the CL paper separate was to encurage use of cl in easy way to be bound. If we provide no guidance on how complex types be used, we might be defeating that it be done in standard way. FOr this release they are simple. In next release we talk about what any XML structure might be. Proposed RULE: For release of 1.0 of the Code List rules we will mandate a simpleType for the CodeContentType. We will examine in future versions of the Code Lists rules, guidelines for using XML for expressing hierarchy in code values. Accepted. (c) Choice of xml:lang for the lang supp component. Eve wants to explore its use. It is not yet a common attribute. It is in every CCT that is using the language code. It is used in the handcrafted module. E: My understanding of the language supplementary component on code ist that it applies to the code content specifiically. G: there is no lang:code in 1.9 as a supplementary component. A: it is metadata about the codelist as a whole. E: instead of using supplementary component listname we put an annotation in to the enumeration for the name of the description itself. In the documentation there is a lang attribute. A code list producer can provide additional annotation documenation inside the annotation in multiple languages if they like. Proposed Design RULE: The NDR SC agrees to remove the codename supplementary component from our recommendations for code markup . HOwver, we recommend that for codelist schema modules chosing to do so, they may provide code expansions and definitions in an annotation element inside each enumeration element wher any natural language information should be conveyed by means of xml:lang. Accepted (d)Use of XLINK for the supplementary components of code that involves URIs. Eve believes that on balance it is not the right match of technologies. . XLINK is not very common If we have multiple attributes that have a linking meaning XLINK does not help XLINK used for hyperlinking, a UBL code list user is not intending to click on something On the other hand the XSD:anyURI is better. Design RULE: The NDR SC agrees not to use XLINK for supplementary components of code tha t involve URIs but rather to use the XSD:anyURI and to name those attributes according to our usual naming rules. Agreed. A: has anyone implemented XLINK as a production system. Yes but not generic enough usually for link management. 7. Context Methodology update Eduardo has not received any comments except from Mark. He urges people to review it. Eve is willing to review it. Kris says it is difficult to comment if only a couple of people get it. Eduardo will send it to the NDR list. It will be distributed in Word. 8. Embedded Documentation For reasons of expediency Arofan is proposing that we go ahead with XHTML and revisit it for future releases of the UBL schema. The structures in Gunther's document could be ported to XHTML but feels they could be better expressed in Docbook. eve thinks that even simplified Doockbook is very large. GUnther's subset of simplified Docbook in the final version of the document how we can do a simplified version of ref-entry. XHTML with classes is as good as Docbook A: is XHTML used to capture other information aside from this. Proposed Design Principle It is the intention of the NDR SC to use XHTML Basic as proposed in the NDR document for the purposes of documenting information other than CCTS that already has a structure. This has been voted on and agreed during this meeting which has quorum. 9. Updates on status of Local vs. Global (Jim) What is the status since last week? Have there been more comments now that the discussion period has been extended? Eve has sent out comments In course of her review she identified false assumption about constraints being operated under. Howver, she saw a compromise we may want to consider. False assumption if you have to use global elements you have to have the object class name on everthing. G: if we want to distinguish them uniquely we need to use it. E: we never said we had to distinguish them all uniquely G: you won't get consistent tag names E: this is true if you don't However, with local elements you will have same inconsistency. For example, there are number of elements called name. They are bound to the name BBIE/CCT. THis occurs right now in the UBL library and the UBL name for al of them let's them be called name, they are all bound to the ssame type and are in different parent elements and could be distinguished by an XPATH. That situation would hold if we had global elements if we agreed that they did not have to be distinguished uniquely. e..g houseName, inside Addreess. You have HouseName and HouseNumber even bound to the name element, we chose for semantic clarity to put House on it. You would still have therefore inconsitencies in naming. Using global elements forces us to call it PartyName, you can't just call it name in Global elements. It is unlikely that you would be able to reuse this as the structure is different. G: Tag names are derived from dicitionary entry names. E: It is two different XPATHS and two different templates and you are not trying to share and reuse the same thing. Reusability is questionable in that case. G: The dictionary entry name is the basis of everything. E: The dictionary entry name is at a more abstract level than local vs global. G: The biggest problem is the incosistencies. E: These are reflective of the differences inthe libraries E: A compromise suggestion. I suspect the biggest source of problems with tag name explosions is all centered on IDs and anyother leaf nodes you want to constrain e.g. codes. IDs are all going to have their own types, but you have a problem you have to call it ShippingContentID etc, what if in a limited set of cases everything is global except ID elements are locally qualified. Eduardo: Do we have a good definiton of ID or are we going to get in to a battle about this. E: These elements would have a representation term of ID. Eduardo: This is very promising. E: It is easy for us to make an exception to the generic rule. The whole code list rules paper would want to be duplicated and become an ID rules paper. The line drawn between IDs and codes went to far in CCTS. G: 95% of IDs are proprietary. Most of them defined by organizations. A: We want to look at the work of LCSC. G: All IDs change too often e.g. life time of a product. E: If in the future we want to have specialized types the best way to acheive this is via local elements. G: Everybody has their own thinking on this. A: Move towards standardization are very slow for IDs G: IDs are only one example of problems with the global elements. E: Would be willing to do local qualified elements for certain classes of leaf elements. A: Would like to explore this further. A: Let's get a handle on the exception cases and come up with a way of solving them. 10. Containership (Arofan) Discussion of Arofan's proposed rules and narrative. See http://lists.oasis-open.org/archives/ubl-ndrsc/200303/msg00027.html Deferred 11. Polymorphism Matt will write something on polymorphism. There is something that Matt can put out of XML 2002 written by Eduardo and Arofan. Eve incorporated this material into her UBL presentations and will dig it up and send it to Matt. 12. AOB none Adjourned Y:58 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>