[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [codelist] CVA scope creep?
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]