Re: [codelist] CVA scope creep?

["Anthony B. Coates (DES)"<anthony.coates@documentengineeringservices.com>]

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  
<gkholman@cranesoftwrights.com> wrote:

> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

-- 
Anthony B. Coates
Associate Director
Document Engineering Services (Limited)
UK: +44 (20) 8816 7700, US: +1 (239) 344 7700
Mobile/Cell: +44 (79) 0543 9026
Skype: abcoates
anthony.coates@documentengineeringservices.com
http://www.documentengineeringservices.com/