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>