[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.