[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Minutes for 17 April 2002 UBL NDR SC meeting
Minutes for 17 April 2002 UBL NDR SC meeting
1. Roll call (quorum is 8)
* Bill Burcham YES
* Mavis Cournane YES
* Mark Crawford
* Fabrice Desré
* Matt Gertner YES
* Arofan Gregory YES (joined x:10)
* Phil Griffin YES
* Jessica Glace YES
* Eduardo Gutentag YES (left x:58)
* John Larmouth
* Eve Maler YES
* Sue Probert
* Lisa Seaburg
* Gunther Stuhec YES (joined y:27)
* Paul Thorpe YES
Quorum not reached as of x:04; we proceeded informally. We reached
quorum at x:10.
2. Acceptance of minutes of previous meeting
10 April 2002 F2F meeting:
http://lists.oasis-open.org/archives/ubl-ndrsc/200204/msg00019.html
Accepted.
3. Adoption of agenda
Adopted.
4. Status of NDR document production/outline
Mavis's outline from last time:
http://www.oasis-open.org/committees/ubl/ndrsc/drafts/draft-ndrsc-designrules-outline-00.doc
She will update when there are more changes to be made.
5. Tag structure decisions
SWIFT comments:
http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-arofan-tagspec-03_SWIFTcomments.doc
Global attributes:
- Gunther has designed some UBL-specific global attributes into
the schemas, but we're unsure that (some of) these attributes are
well enough motivated. Ideally these sorts of things should be
accounted for in the spreadsheet, and therefore the methodology.
- We don't currently say when to use these, besides implying that
they should be used for "global ID" attributes. There are two
considerations: when to choose existing external global attributes
like xml:lang, and when to choose to design UBL-specific global
attributes. Right now, we don't see any particular benefit to
making "common properties" of all elements be declared as global
attributes. The schema code doesn't get any shorter (however,
we imagine that the dictionary could have a single entry instead
of one entry per assignment of a local-but-common attribute to
each element).
We propose the following rule: A global attribute should be used
only when its semantics are absolutely unchanged no matter what
element it's used on, AND it's made available on every single
element. This goes for both external and UBL-specific ones. This
allows common attributes that are everywhere but are *not* global,
and that need documentation of their meaning in each XML
environment in which they're used.
New ACTION: Eve to send mail to the LC SC outlining the question
about the existing global attributes and asking about the best way
to justify them (and others). This should be phrased in
XML-neutral terms (e.g. global attributes as common properties of
all objects).
- We're happy to say that UBL-specific global attributes should be
named just like regular attributes and subelements (that is, as
properties of an object class). Note that, by definition, the name
of such a property *must* be consistent across all objects.
New ACTION: Mavis to put the two proposed rules in the tag
structure/NDR document.
Mixed content:
- We agree that mixed content in business documents is basically bad
news. Only description fields that need some "publishing freedom"
are likely to need mixed content, such as product descriptions in
catalogs. We need to add a rule about avoiding mixed content in
most cases. The reasons it's bad are:
. White space is difficult to handle and complicates processing.
. Mixed content models allow little useful control over cardinality
of elements.
- We're not sure we like "Prose" as an RT. Other options we've
discussed are: Text (already used, though it's our default and it
gets elided from actual tag names), Poetry (kidding), Narrative,
Mixed, AnnotatedText, Pub[lishable]Text, [X]HTML.
ACTION: Eve to ask the LC SC for a variety of examples of content
that needs "publishing" information in them, e.g., bold, italic,
paragraphs, etc. We suspect that XHTML is sufficient for all such
needs, and we want them to try and prove to us that this isn't
sufficient.
Empty elements:
- Can we confirm that we don't believe in empty elements? VOTE: Do
we accept Gunther's rationale for why empty elements should not be
used? Unanimous YES.
Complex types that contain <simpleContent>:
- Gunther has conventionally used the infix "Content" for the simple
type corresponding to the content of a complex type that has simple
content. For example, CodeContentType is a simple type trivially
restricting xs:token, and it's used in setting up CodeType, which
is a complex type that adds attributes to an element containing a
code.
- There are several questions about the current approach.
Considering that most of the simple-content types are trivial
restrictions of an XSD type, do we really need these? Can the
CoreComponentType.xsd file merely have these reference the XSD
type directly in some/all cases, which amounts to using an
anonymous type in a sense? There is a proliferation of
types (CodeListAgencyIdentifierType, CodeListIdentifierType,
CodeContentType, etc.). Having a UBL-named type may be useful
for handling contextualization (through derivation) and also,
just in general, for data binding (schema compilation and database
handling).
- Gunther asks about how users can set facets on our types. Arofan
points out that the LC SC currently isn't capturing very precise
facet-type information, such as how long a number is. Gunther's
examples are: setting the number of digits in the fraction of an
amount (e.g., a price), and constraining identifiers to the number
of characters/digits that are exactly allowed. Arofan wants to
define some facets out of the box. He notes that xCBL did a lot
of work on this and we can probably use their ready-made types.
Gunther has also done some work on this.
New ACTION: Arofan and Gunther to take up with the LC SC the
potential business requirement for making types more precise.
- How to name complex types, simple types, and complex types with
simple content: Deferred!
6. RT/CCT comments and status
Bill's latest effort along these lines:
http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-burcham-ccts-cmts-00.zip
CCSD discussions on this point:
http://lists.oasis-open.org/archives/ubl-ndrsc/200204/msg00023.html
We noted that the CCSD group seemed to be going in the direction of
one-to-one mappings, which raises (to us) the question of why you
need both. Arofan is still signed up to propose a list that migrates
structural characteristics from RTs to CCTs and shows which (possibly
multiple) RTs can be served by each CCT.
7. Code lists
Deferred!
8. Elements vs. attributes
Deferred!
9. Action items and prioritizing our next chunk of work
Summary of work to be done:
A External recommendations for changes to CCTS [IN PROGRESS]
A Code lists
A Modnamver
A NDR document production [IN PROGRESS]
A Review the purchase order schema design [IN PROGRESS, sort of]
A Officially decide elements vs. attributes
A Officially decide empty elements [DONE]
B Tag structure [NEARLY DONE]
B Containership
B Fixed vs. varying types
C Dates and times
Schedule:
April 24: Code lists, tag structure, RT/CCT comments (1hr)
May 1: (2hr)
May 8: (1hr)
May 15: (2hr)
May 22: (1hr)
May 29: (what else?), approve NDR document for distribution (2hr)
June 5-9 (the F2F meeting itself, if all goes according to plan)
Current ACTION items:
Everyone:
- A: Review the modnamver paper, the examples, and the 0.64 schema
distribution.
- A: Read Matt's types paper and see if we want to prioritize it
higher.
Mavis:
- A: Tag structure/NDR changes
Eve:
- A: Code list paper
- A: Help Mavis with Word styles in NDR document
- A: Get LC SC feedback on global attributes
- A: Get LC SC feedback on "prose" needs
Bill:
- C: Role model paper
Arofan:
- B: Containership paper
- A: Attempt a more specific RT/CCT proposal
- A: (with Gunther) Take up facet discussion with LC SC
Gunther:
- C: Date/time paper
- A: (with Arofan) Take up facet discussion with LC SC
10. Adjourn
Adjourned 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