OASIS Code List Representation TC

Hi folks,

With the advent coming of W3C Schema 1.1, there is an opportunity to 
add to the scope of context/value association (CVA) files ... but I'm 
worried about scope creep.

Right now a CVA file is only associated contexts with code list values.

It would be easy to add to CVA files the association of contexts with 
arbitrary values expressed in XPath.  Such values could be 
requirements such as qualifying data types ... for example by 
imposing a string length:

    string-length(.) = 35

In a W3C Schema 1.1 implementation of CVA file this would translate 
into a combination of enumerations, facets and assertions.  It would 
mean being able to express all of the requirements in one file rather 
than a combination of files.

Similarly, in a Schematron implementation of CVA file this would 
allow one to express all of the requirements in one file rather than 
a combination of files.

I've completed the prototyping and it meshes well with the current 
design.  But I'm at the stage where I can easily unwind my changes if 
you think this is a non-starter.  I don't want to waste more of my 
time on it if the committee feels strongly it is out of scope.

Managing all of one's context/value associations in a single 
declarative fashion sounds attractive to me, but do you believe going 
beyond the association of code lists going beyond our scope?  Do you 
need to see a more polished prototype before offering an opinion?

Thanks for your thoughts on this!  If I don't hear any disagreements, 
I'll prepare the next draft for committee review.  If Tony gets his 
genericode change proposals posted soon, then we an cover off both in 
our first return call (not yet scheduled).

. . . . . . . . . . Ken

p.s. please let me know if anyone doesn't have Skype with which to 
participate in committee conference calls.  In the UBL committee 
we've been having a lot of success in conference calls and for remote 
participation in our face-to-face plenary using http://www.yugma.com 
for desktop broadcast.  The Skype Edition is a free download and 
install (third column on home page) and need only be downloaded by 
those who are sharing their screen with others ... if you plan only 
to view someone else's screen, there is nothing to download in 
advance.  You just sign into a web page without downloading anything 
and you get to view the host's screen.

--
XSLT/XQuery/XSL-FO hands-on training - Los Angeles, USA 2009-06-08
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

It's a good question.  It's definitely scope creep in one sense, the sense  
that it takes CVA beyond the bounds of code lists, and beyond the scope of  
the CLRTC.  At the same time, it's obvious that it's exactly what users  
would want to do.  Why should they care about what our internal OASIS  
scope boundaries are?

Still, as an OASIS TC, we have to give some thought to scope.  I seem to  
remember we discussed this issue once before, and I suggested two  
possibilities:

  1) create a separate OASIS TC to carry forward the extension of CVA into  
something bigger, with a scope beyond code lists.  That would parallel the  
way the CLRTC was spun off the UBL TC;
  2) allow for this functionality in the CVA Schema, but document it  
non-normatively (at least in an official sense) in an appendix to its  
spec, so that the normative part is within scope.

Perhaps someone from OASIS could suggest what is best.  Mary?

Cheers, Tony.

On Sun, 26 Apr 2009 01:22:14 +0100, G. Ken Holman  

At 2009-04-26 21:51 +0100, Anthony B. Coates (DES) wrote:
>It's a good question.  It's definitely scope creep in one sense, the sense
>that it takes CVA beyond the bounds of code lists, and beyond the scope of
>the CLRTC.  At the same time, it's obvious that it's exactly what users
>would want to do.  Why should they care about what our internal OASIS
>scope boundaries are?

Agreed.

>Still, as an OASIS TC, we have to give some thought to scope.  I seem to
>remember we discussed this issue once before, and I suggested two
>possibilities:
>
>  1) create a separate OASIS TC to carry forward the extension of CVA into
>something bigger, with a scope beyond code lists.  That would parallel the
>way the CLRTC was spun off the UBL TC;

True, but I think that was a much cleaner definition of a topic scope 
suitable for a new TC.  I'm very reluctant to trigger the overhead of 
a new technical committee whose scope would probably only be the one 
extension of this schema and nothing else.

>  2) allow for this functionality in the CVA Schema, but document it
>non-normatively (at least in an official sense) in an appendix to its
>spec, so that the normative part is within scope.

Kewl idea!  But in the conformance section while such non-code-list 
constraints would be entirely optional, if they were present they 
would need to conform to the committee definition and schema components.

I think your suggestion can justify keeping it in the one CVA specification.

>Perhaps someone from OASIS could suggest what is best.  Mary?

Thanks for your thoughts on this, Mary!

. . . . . . . . . Ken

--
XSLT/XQuery/XSL-FO hands-on training - Los Angeles, USA 2009-06-08
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

In retrospect, maybe we could take a more liberal interpretation.  One of  
the future things I've vaguely thought about for genericode is to provide  
some support for "non-enumerable code lists", lists where it isn't  
practical or otherwise possible to list all of the values.  One thing that  
you can provide for such lists is a set of facets that at least partially  
validate codes.

So, one could argue that adding support for facets to CVA is a way of  
providing support for such code lists.  If it happens that it's also  
useful for other things that aren't directly related to code lists, that's  
just a happy side effect.  How does that sound?

Cheers, Tony.

On Sun, 26 Apr 2009 22:10:17 +0100, G. Ken Holman