[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of Atlantic UBL TC call 3 November 2010
MINUTES OF ATLANTIC UBL TC MEETING
WEDNESDAY 3 NOVEMBER 2010
ATTENDANCE
Peter Borresen
Jon Bosak (chair)
Betty Harvey
G. Ken Holman
Ken Vaughn
STANDING ITEMS
Additions to the calendar:
http://ubl.xml.org/events
None.
Review of Pacific call minutes
No comments.
UBL 2.1 STATUS
PLB: The PSC has reviewed 80 issues and formed a solution team
to meet and resolve these issues before the end of the review
period 24 November. PLB will be in touch with AS regarding TSC
issues.
UBL NDR WORK
See discussion below following our usual agenda and tracking
items.
NDR CHECK (NIST TOOL)
Nothing new this week.
PROCUREMENT SUBCOMMITTEE COCHAIR
PLB: We will wait for the upcoming PSC F2F meeting to discuss
this.
2011 UBL TC F2F MEETING SCHEDULE
30 May - 3 June 2011
Ankara, Turkey, at Middle Eastern Technical University
October/November 2011
As we agreed some time ago, GKH is checking to see whether
we can secure a meeting venue in Ottawa.
TC CONCALL SCHEDULE
Next week, DST will end in North America, and the UTC times for
our Atlantic and Pacific calls will shift *forward* one hour to
maintain the usual call times in North America and Europe.
Week of 2010.11.15 Regular schedule
Week of 2010.11.22 >>> NO MEETINGS <<<
Week of 2010.11.29 Regular schedule
Week of 2010.12.06 Regular schedule
Week of 2010.12.13 Regular schedule
Week of 2010.12.20 >>> NO MEETINGS <<<
Week of 2010.12.27 >>> NO MEETINGS <<<
Week of 2011.01.03 Regular schedule
Jon Bosak
Chair, OASIS UBL TC
==================================================================
TRACKING ITEMS
UBL 2.1 NDR ILLUSTRATIONS
UBL 2.0 NDR IMPLEMENTATION GUIDE WIKI
http://wiki.oasis-open.org/ubl/NDR_2.0_Implementation_Guide
CCTS 2.01 DMR
ACTION (2009.06.30): TM to circulate a draft CCTS 2.01 DMR
to the TC for review.
Pending.
==================================================================
UBL NDR WORK
As planned, most of a very productive meeting was spent
discussing the issues raised by KV in this message:
http://lists.oasis-open.org/archives/ubl/201010/msg00000.html
The issue numbers in what follows all refer to the numbering in
the message above.
Issue 7. Extensions
See message from GKH at
http://lists.oasis-open.org/archives/ubl/201010/msg00022.html
(Note that the line
<corpx:CorpXOtherItem>abc</corpx:CorpXOther>
should read
<corpx:CorpXOtherItem>abc</corpx:CorpXOtherItem>
I.e., this is not intended as an example of
non-wellformedness.)
JB: Please review the original motivation for the extension
mechanism.
GKH: The original purpose was to provide a home within an
instance for non-UBL constructs (as required, for example,
between two trading partners) in such a way that the
document instance is not considered invalid by other parties
and therefore rejected. It provides a safe home for
information that you may or may not care about. If you
care, then you can write a schema that does validate the
added information. We've implemented this in a way that
enables validation simply by changing a single schema
fragment that is referenced by all of the document schemas.
JB: What gets validated if KV's approach is accepted?
GKH: Exactly what you want to be validated; everything else
[in the extension area] is ignored. So if a party agreeing
to specific extension content doesn't follow the agreement
and sends something that's not in conformance with the
agreement, the nonconformant piece is simply ignored.
KV: Note that in a multiple-trading-partner situation, the
partners will add extensions as needed; that is, an instance
may contain multiple extensions for multiple partners, some
of which should be ignored by any partner in particular.
PLB: This is the behavior we want. Validation belongs to
the particular subset; it's customization-dependent.
JB: What changes between PRD1 and PRD2 if we accept KV's
approach?
GKH: We would substitute a different schema extension
fragment. In operational terms, the change means that the
second example [with typo corrected] under #2 in the message
of 30 October linked above will be caught by PRD1 but
ignored by PRD2. In other words, an instance containing an
unexpected apex element will be marked as valid.
JB: Do we want to adopt this change?
GKH: In this case, simplicity wins over completeness. PRD1
didn't provide a complete validation solution anyway due to
limitations in W3C Schema (none of this presents a problem
in Relax NG).
KV: We could provide both approaches in PRD2; after all,
this is a customization issue.
BH/JB: Having one way in the release is best.
AGREED to keep things simple by providing just one schema
fragment and documenting the alternative.
JB: The proposed approach will require downstream processing
to catch and deal with an unexpected apex element. But we
don't (shouldn't) be relying on validation to resolve all
possible issues anyway.
AGREED to adopt KV's suggestion.
ACTION: GKH to revise the extension module, the signature
module, and the related documentation. (GKH has already
signed up to revise the Digital Signature Profile
document for review by the UBL Security SC.)
The group then turned its attention to the remaining six issues
from KV's message of 1 October.
Issue 1: Core Component Parameters Schema
Issue 2: DEN terminology
JB: These are both CCTS-related documentation issues
(agreed) and as such, items to be worked on by an (as yet
undefined) NDR work team.
Issue 3. Naming rules
JB: This relates to a straightforward but quite substantial
work item: Start with current practice (where consistent!)
and make sure that the rules correctly describe it.
GKH: It ties into proposed UBL Modeling Guidelines as well.
AGREED (provisionally) to form an NDR Team consisting of
KV, BH, GKH, MG and MC to work on these items.
ACTION: KV and BH (together with MG if available) to meet
in person in or around DC and include MC (if available)
and GKH by phone; follow up with MG and MC via email
review and possible additional telcons.
Issue 4. Why not allow xsd:choice (aka OR groups) in UBL?
JB: Here is a relevant thread from 2004 (note that this is
not exhaustive of the discussion of the subject that led up
to its treatment in the original UBL Naming and Design
Rules):
http://lists.oasis-open.org/archives/ubl-ndrsc/200401/msg00009.html
http://lists.oasis-open.org/archives/ubl-ndrsc/200401/msg00010.html
http://lists.oasis-open.org/archives/ubl-ndrsc/200401/msg00011.html
http://lists.oasis-open.org/archives/ubl-ndrsc/200401/msg00012.html
http://lists.oasis-open.org/archives/ubl-ndrsc/200401/msg00013.html
http://lists.oasis-open.org/archives/ubl-ndrsc/200401/msg00016.html
The question at this point is whether there is a genuine UBL
use case that demands OR groups.
GKH: Worried about introducing a different way of doing
things this late in the game. As Eve Maler noted in the
thread above, we can't express OR groups in our
spreadsheets. The usual use case for OR is addressed in UBL
by providing optional alternatives; coincidentally, this
issue has come up today in a discussion on ubl-dev:
http://lists.oasis-open.org/archives/ubl-dev/201011/msg00000.html
http://lists.oasis-open.org/archives/ubl-dev/201011/msg00001.html
http://lists.oasis-open.org/archives/ubl-dev/201011/msg00002.html
http://lists.oasis-open.org/archives/ubl-dev/201011/msg00003.html
[and subsequent posts]
KV: ITS (ISO TC 204) sees no reason to exclude xsd:choice.
It's agreed that this wouldn't break UBL backward
compatibility, and while there's no strong preference for
xsd:choice in future UBL documents, it would be an advantage
in developing sets of NDR that are broader than UBL's.
GKH: Are there mutually exclusive properties in UML?
KV: No for BBIEs, yes for ASBIEs.
GKH: So xsd:choice would only be used at the ASBIE level and
mutual exclusion would otherwise have to be implemented by
layering on business rules, just as in UBL.
KV: Suggestion: we better document the decision to exclude
xsd:choice in the NDR so that users outside of UBL are aware
of the alternatives.
GKH/JB: We don't want to make support for xsd:choice a
requirement for UBL tools.
AGREED that in the absence (so far) of a compelling UBL
use case for xsd:choice, the tools issue means that we
won't touch the original decision in the UBL 2 life cycle
except for documentation.
ACTION: The NDR Team (see above) to note in the revised
NDR document that the UBL decision to exclude xsd:choice
doesn't necessarily apply to all efforts.
Issue 5. Why do we include complexType definitions in the
Common Basic Components? (There are 821 cbc elements and 821
corresponding abstract types.)
JB: It's clear that the extra level of abstraction adds to
the complexity of the design.
GKH: This is not a reason to change it now.
JB: Why did we do this?
KV: E.g., "...nametype..." vs. "text"....
GKH: Because without the abstract types we lose the business
semantics and would just be doing text processing. That's
why it was structured this way.
KV: This should be explained in the documentation. A larger
question is how generally applicable we're trying to make
the NDR. For example, ITS (ISO TC 204) is revising how to
use XML and will be using its own data registry conventions
rather than CC naming conventions, though it's conceptually
similar. So there are issues around how we explain things.
We need a widely recognized standard.
JB: This is largely a resource problem.
KV: (Offers to spend time developing an OASIS NDR Standard
that is flexible enough to extend but not specifically
generic in parallel with the ISO ITS Standard)
AGREED to work toward eventual OASIS Standardization of
the UBL 2 NDR.
ACTION: The NDR Team (above) to identify generalization
points within the UBL NDR document.
Issue 6. Requiring code list version identification
JB: It appears to be agreed that the mechanism is in place
to do this, but currently the metadata is optional. We
can't change this to "required" in UBL 2, so for now this is
a user problem.
GKH: It's just another business rule if a particular
community wants to make the meta mandatory.
AGREED to document this as a usability or "best practices"
issue in a future revision of the Guidelines for
Customization.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]