[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