OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: UBL Methodology for Code List and Value Validation - version 0.8 draft 6


Fellow UBL TC members,

After two months of deployment of the earlier version, I've just 
posted the latest version 0.8 draft 6 of the UBL Methodology for Code 
List and Value Validation:

   http://www.oasis-open.org/committees/document.php?document_id=24518

Changes found in this draft:

(1) - addition of <ValueList key=""> attribute to specify a 
particular key from a genericode external expression in the case 
where the expression has multiple keys to choose from (this is 
optional if there is only a single key, but mandatory if there are 
multiple keys);

(2) - in response to user feedback, the meta data stylesheet 
functionality has been rewritten to be parameterized to take away the 
need to write XPath addresses for the most obvious relationships of 
meta data properties to coded information items (though the former 
functionality of explicitly writing an XPath address is still 
available as an option);

(3) - in response to user feedback, the meta data checking of 
<Context item=""> attributes is now namespace-safe and no longer 
relies on prefix recognition (though the former functionality of 
explicitly writing an XPath address is still available as an option);

(4) - repaired "test-all.bat" for proper detection of return codes;

(5) - simultaneous support for genericode 0.4 and genericode 1.0; and

(6) - support for a key comprised of multiple columns;

I'm getting fewer and fewer issues reported about the functionality 
of the methodology so I think it is almost stable enough to call it 
"ready to go to version 1.0".

Meanwhile, after discussion in New York City in May, the UBL TC 
agreed in principle during its teleconferences (copied below) that 
this methodology be transferred to the Code List Representation 
Technical Committee.  In the CLRTC this would represent but one of 
possibly many ways to validate the use of genericode files.  I'll 
take this transfer issue, and this particular Version 0.8 draft 6, to 
the CLRTC for ratification.  I will then take 0.8D6 through any 
modifications desired by the CLRTC and then marshal it through the 
steps to a CLRTC methodology 1.0 as an OASIS standard under a new 
generic name that does not include "UBL" in the title.  When it 
becomes an OASIS standard its vocabularies will have new namespaces.

The timing is such that it will take a few weeks before the CLRTC 
confirms this, so there is some time for more feedback from users of 
the methodology.  If you are using this methodology, would you please 
try out the new stylesheets and report any issues you may find.  Any 
feedback on the wording of the specification will also be very valuable.

Given the number of changes made since the last draft, I would 
appreciate anyone using the methodology to put the latest stylesheets 
through their environments to check for any problems.

Thanks to everyone for their feedback already received to improve 
what is there!

. . . . . . . . . . . . . Ken

>Date: Tue, 22 May 2007 12:01:41 -0700 (PDT)
>From: jon.bosak@sun.com
>To: ubl@lists.oasis-open.org
>Subject: [ubl] Minutes of Pacific UBL TC call 21|22 May 2007
>
>MINUTES OF PACIFIC UBL TC MEETING
>TUESDAY 22 MAY 2007
>...
>DISPOSITION OF CODE LIST METHODOLOGY WORK
>
>    Should we transfer the code list methodology to the OASIS Code
>    List Representation TC?
>
>    GKH: The UBL label misleads some users into thinking that the
>    methodology is slanted toward UBL.
>
>    TM: It should be something like "Schematron-based code list
>    methodology."
>
>    GKH: We would continue to use UBL as the exemplar.  In
>    practice, the transition would simply mean changing the title
>    and the introductory section of the paper.  The namespaces
>    would have to change, but that's not a problem if we make the
>    transition before issuing the first of the code list snapshotes
>    we discussed at the meeting in Manhattan.
>
>    JB: This was the reasoning behind the transfer of genericode to
>    a separate TC.
>
>    TM: Viz., that it can be used with more than UBL.  We should
>    have a guideline that we encourage the adoption of the CL
>    methodology.
>
>    JB: Are both TCs operating under the same IPR mode?
>
>    GKH: Yes.
>
>    AGREED to transfer the CL methodology to the Code List
>    Representation TC (pending review in this week's Atlantic
>    call).

>Date: Thu, 24 May 2007 08:26:27 -0700 (PDT)
>From: jon.bosak@sun.com
>To: ubl@lists.oasis-open.org
>Subject: [ubl] Minutes of Atlantic UBL TC call 23 May 2007
>
>MINUTES OF ATLANTIC UBL TC MEETING
>WEDNESDAY 23 MAY 2007
>...
>DISPOSITION OF CODE LIST METHODOLOGY WORK
>
>    See Pacific minutes.
>
>    TonyC: This has been discussed in the CLRTC but no final
>    decision has been made yet.  The CL methodology works for UBL
>    but will probably fail with some uses of genericode lists, so
>    the CLRTC has to think about this.  An agreement in principle
>    would be OK.
>
>    AGREED to approve the transfer in principle pending further
>    investigation by the CLRTC.
>
>    JB: We need a decision from the CLRTC before we can start
>    issuing code list support updates.


--
Upcoming hands-on training:  UBL Oct 1-3,5, Code lists Oct 2, 2007
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]