[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Minutes for 3-6 June 2002 UBL NDR SC meeting
Minutes for 3-6 June 2002 UBL NDR SC meeting
Minneapolis, MN (with X12)
Everyone PLEASE NOTE your action items and do them! Many of us have
a June 15 XML2002 deadline. Go to http://www.xmlconference.org to
submit your paper abstracts.
Voting members attending:
Mavis Cournane
Mark Crawford
Jessica Glace
Arofan Gregory
Eduardo Gutentag
Eve Maler
Gunther Stuhec
Relatively constant observers:
Bob Glushko
Kris Ketels
No votes were taken. These minutes include some notes from the
Context Methodology meeting as well.
* * *
Summary of action items:
Mavis:
- Review V04 of design rules and Gunther's script for new issues.
- With Gunther, add *Type/*ContentType info to the NDR document.
- With Eve, submit NDR topic to XML2002 by June 15.
Eve:
- Add list of future work to portal.
- Cancel current NDR SC telecon reservation.
- Set up CM SC telecon and explain CM Phase 1 idea to Matt/Bill.
- Extract code list chapter and finish it (see list of issues below).
- Write a code list FAQ.
- Do an analysis of the supp-components-of-supp-components problem.
Mark:
- Bring up code list recommendation to the liaison SC.
- Submit topic on building the UBL community to XML2002 by June 15.
Eduardo:
- With Arofan/Matt, submit Context Meth topic to XML2002 by June 15.
Gunther:
- Submit UBL tools/techniques topic to XML2002 by June 15.
- Revise Dates/Times paper.
* * *
3 June 2002
ACTION: Mavis to review V04 of design rules document for missed bits,
work with Gunther to see which have had "implicit decisions" made,
and bring them to the NDR SC's attention.
ACTION: Eve to put a list of future position papers and other future
planned work on the portal.
ACTION: Mavis and Gunther to get the *Type and *ContentType
recommendation into the NDR document.
Regarding testing the "code list vision" on external agencies: We
need to shop our recommendation to the agencies in question, and also
officially take this question to the Liaison Committee.
ACTION: Mark to discuss the code list vision with the liaison
committee.
We discussed making sure that UBL NDRs are covered at XML2002.
ACTION: People to submit papers to XML2002: Eduardo and Arofan on CM,
Mavis and Eve on NDR, Mark on building the UBL community, Gunther on
UBL tools and techniques. Abstracts must be sent by June 15 to
www.xmlconference. org.
* * *
4 June 2002
*Deliverables going forward:
We need to work hard on getting the NDR document more complete and
fleshed-out, for delivery at least two weeks before the next F2F
(which we're guessing is roughly the first week of October).
*Telecon schedule:
We agreed to continue meeting weekly. We agreed to use Eve's
reservationless account.
ACTION: Eve to send mail to the NDR SC asking if shifting the telecon
schedule out half an hour is better, worse, or the same.
ACTION: Eve to cancel the currently scheduled meetings and ensure
that future agendas list the new number.
*Notes for LC/NDR joint session:
- We recommend that they submit an LC talk to XML2002!
- There needs to be enough facet information in the spreadsheet so
that the schemas can be generated with tighter validation. We fear
that adding multiple columns for "semantic" facet information would
be way too heavy. We'll try to suggest that they supply
information in a single column, in a canonical XSD- friendly form.
For example, something of RT "Number" could potentially be
customized with facets like this:
minInclusive="1"
maxInclusive="7"
(They ultimately chose to use more columns.)
- It's important to properly identify the contexts attached to their
models. We should give them a heads-up about the latest Context
Methodology thinking on component cardinality. Namely, we're
considering developing a set of context rules that transform from
an "ur-schema" with lots of optional elements to the "80/20
schemas" (which are the ones that they're developing and that have
"real" cardinalities).
*Local vs. global discussion:
If we change elementFormDefault to "qualified", we retain the ability
to declare multiple elements with the same name but different types
(if we so wish). Do we also gain the ability to reference UBL
elements directly in doing XSD derivations of all kinds? Using
"global" elements instead (i.e., referencing element declarations
from inside type declarations rather than declaring the elements in
situ) would preclude the same-name- different-types ability.
We noted that parsers need extra context when processing fragments
containing local elements, because without xsi:type or without the
parent element being present, the subelement could be ambiguous.
We need to continue these discussions.
* * *
5 June 2002
*Code lists:
We discussed the issue of code lists vs. identifiers that is
currently being worked in CCSD. We are able to continue on our
current path no matter what direction they take, we think.
We still have a question about the "tiny code lists" that exist just
for UBL convenience (e.g., yes/no/other, or time slots in 15-minute
increments, to take two examples from xCBL), and may not need to be
namespaced and referenceable and extensible by others. If UBL needs
these, we need to make an exception for them in our recommendation.
Let's call these "locally scoped code lists" because UBL would be
defining and using them itself while not allowing their reuse by
others (and because they're not all necessarily "tiny"). Several of
us have considerable doubt about the benefits of making *any* code
lists locally scoped, since we can't predict ahead of time that no
one else would want to use it. Also, it would be cool to pre-compile
GUI controls that know about standard codes for drop-down lists.
We should provide conventions for documenting correlations between
codes from disparate sources while not impacting the schema (that is,
this should be done in the documentation).
We do agree that canonical documentation should be provided in
external code list modules. This brought up the question of the
appropriate way to put structured documentation into both UBL and
external modules. The correct way to use XSD documentation elements
is:
<xsd:documentation source="uriReference">
...any stuff...
</xsd:documentation>
where the uriReference is a hyperlink to the source of the
documentation that the content came from. There is no provision for
putting non-XSD attributes on the documentation element.
We face some choices:
- Simple strings inside
- XHTML inside
- Some UBL-documentation-specific elements and attributes to indicate
the "semantics" of the documentation field, such as the "UBL
definition" of an element or attribute
- A combination of UBL-specific stuff and internal XHTML markup
Here are requirements on the documentation solution for code list
modules:
- No UBL-specific markup, because this will discourage external
schema module producers from using the fields.
- Allow only markup that's extremely widely supported. XHTML Basic
was suggested. The CLASS= attribute could be used as a way to
subclass documentation fields. (Eduardo checked out XHTML Basic,
and thought it would be suitable for this purpose.)
The whole code list type should have the following documentation
fields:
- Code list agency identifier (required)
- "Namespace" from which the agency identifier came (required)
- Code list identifier (required)
- Code list version identifier (required)
- Code list description, possibly including information on other
code lists on which this one was based (optional)
Example:
<xsd:complexType name="AirportCodeType">
<xsd:annotation>
<xsd:documentation>
<xhtml:p class="agencyID">IATA</xhtml:p>
<xhtml:p class="agencyIDIdentifier">EDIFACT3055</xhtml:p>
<xhtml:p class="codeListID">XXXXXX</xhtml:p>
<xhtml:p class="versionID">YYYYYY</xhtml:p>
<xhtml:p class="codeListDesc">
This is a code list covering <xhtml:b>airport codes</xhtml:b>
worldwide.
</xhtml:p>
</xsd:documentation>
</xsd:annotation>
...
</xsd:complexType>
Individual enumerations (but not other kinds of code content types)
optionally can have the following documentation fields:
- A short prose description of the code (Code.Name)
- The language in which the description is provided (Language.Code,
represented as xml:lang)
Example:
<xsd:simpleType name="AirportCodeContentType">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="JFK">
<xsd:annotation>
<xsd:documentation>
<xhtml:p class="codeName" xml:lang="EN">
John F. Kennedy airport
</xhtml:p>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
...
</xsd:simpleType>
* * *
6 June 2002:
*Phase 1 context methodology proposal:
Requirements:
- Can develop your own derivation off of UBL (ur- or 80/20) by
hand-coding (or otherwise generating) an XSD module.
- Must describe, in UBL-approved way, the business context in which
the documents conforming to the derived schema apply.
- Has to be possible to "compute" the context of any derived type.
- Not yet necessary to describe the "delta" between the original and
derived schemas; the context rules language would do this in Phase
2. This would allow (at least indirect) comparison of two schemas
claiming to address the same context.
We questioned whether it's a good idea to encourage very deep
derivation that's far away from ur or 80/20. One idea is to only
allow derivation that sets a context value that wasn't originally set
(e.g., adding a geo to a business process, but not adding to/changing
the business process). This makes the computability a lot easier,
but may disallow some important functionality (we're not yet sure
what).
The values along one context axis have a relationship to each other
(typically hierarchical). This means that it might be possible to
have "MRO" and "direct goods" be under the "purchasing" value, and
thus you could have a type for the generic purchasing case that
factors out the commonalities that all kinds of purchasing share.
Same with industry classifications: GM might be a subset of AIAG.
Thus, developing derived schemas that are "farther away" from 80/20
by virtue of being specializations of an intermediate context value
are "safe". Depth of derivation therefore isn't inherently bad.
However, deriving from a type that has a context value that is *not*
an ancestor of the desired value is dangerous. We want to make a
rule disallowing this, called the Down With Onions rule, or possibly
the Altoids rule. :-)
Eduardo's example: location. If you have a multipart code, such as
continent:country:province: city, you can derive new types for value
fields "lower down" in the value:
T(continent=Americas) -> T'(country=US) ->T''(city=Boston)
But you can't have a type T'''(country=Mexico).
Definition: Context descriptor: An XML representation of the relevant
context values for a schema module or individual type. The
schema/type might be a derived one or an original UBL ur- or 80/20-
one.
We will need to figure out rules for defaulting context descriptors
when they are specified for a whole module vs. an individual type,
and also whether the UBL modules should ever use default context
descriptors.
ACTION: Eve to set up a CM SC telecon, or at least discuss this
proposal with Bill and Matt and see where to take it.
People are pretty comfortable with the Minnesota Nice proposal
(abstract ur-schemas) and the Down With Onions (don't derive from
anything but an ancestor context value) proposal and with the phase 1
context descriptor proposal.
*Progress review:
We need to try to move the code list recommendation to Commitee Spec
level all by itself (apart from the NDR document).
ACTION: Eve to turn the code list chapter into a separate document
and also write a FAQ.
Outstanding issues:
- Consider putting a non-normative section in about code lists
represented in RELAX NG.
- Write about locally scoped code lists.
- Finish writing xsd:documentation info.
*Dates and times:
Gunther walked us through V01 of his paper.
ACTION: Gunther to revise the paper.
*Tools and Techniques coordination:
Gunther does have time to do some maintenance on the script code.
Arofan has been talking to him about using a source code control
system, possibly simply using SourceForge in a private area.
The TT SC is thinking about putting up some tools on the UBL website.
Arofan will rationalize the voting membership of the SC.
*New issues:
- Aggregation of similar information for ease of XPath V1.0
addressing (Gunther issue)
- Referencing of content, e.g. attachments (Gunther is writing a
position paper)
- Identifier references and whether to pass content by reference
(Gunther issue)
- Wildcards
- All priority-B items
- Dates and times
- What to do when supplementary components need supplementary
components?
ACTION: Eve to try and figure out how bad the supplementary-
components-of-supplementary components problem currently is.
- What supplementary components are missing? E.g.,
CodeList.Agency.Identifier is often a code that needs code-list-
related info itself.
- Local vs. global
--
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