Fwd: Re: [codelist] Default letter ballot regarding the Schematron-based validation methodology

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

(third attempt since Sunday August 19)

>Date: Mon, 20 Aug 2007 09:39:01 -0300
>To: "Code List Representation TC" <codelist@lists.oasis-open.org>
>From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
>Subject: Re: [codelist] Default letter ballot regarding the 
>Schematron-based validation methodology
>
>(retry; apologies if this is received twice but I don't see my post 
>from yesterday in the archives)
>
>At 2007-08-19 17:06 +0100, Anthony B. Coates (Miley Watts) wrote:
>>On Tue, 14 Aug 2007 02:43:41 +0100, G. Ken Holman
>><gkholman@CraneSoftwrights.com> wrote:
>>
>>>     That the Code List Representation Technical Committee take
>>>     onto its programme of work the code-list-validation-related
>>>     work item begun in the Universal Business Language Technical
>>>     Committee, and to bring the renamed and revised specification
>>>     through the OASIS process as the CLRTC committee decides.
>>
>>I'm basically in agreement with the CLRTC taking on responsbility for
>>this, subject to the resriction that for this to be a CLRTC document, it
>>needs to focus on code lists *exclusively*, and on genericode exclusively
>>as the code list format.  It should not discuss validation of constraints
>>that are not related to code lists or not related to genericode.
>
>Removing the ability to add other Schematron constraints for 
>business rules to the methodology will, in my opinion, greatly 
>reduce the applicability of the specification in real world 
>deployments.  I think it is a critically important component of the 
>methodology.
>
>The document already focuses on genericode as the list format and 
>the fact that the prototypical implementation included may support 
>others is just an aspect of the stylesheet design.  I would not 
>re-engineer the stylesheets to hardwire only the use of genericode.
>
>>This will narrow the focus of the document compared to the UBL version.
>
>I'm not sure it would be that much, but we can discuss specifics in committee.
>
>>There are many references to UBL and trading partners that are not
>>appropriate for a CLRTC document, and these should be removed or replaced,
>>but I am assuming the document will be rewritten for CLRTC.
>
>I had assumed the document was already sufficiently rewritten, so 
>this is important feedback.
>
>>In particular, much of the text could be expressed more simply and 
>>concisely,
>>and we should try and to this.
>
>I'll take another crack at it, then, but that can be done as part of 
>the feedback in its development.
>
>The question at hand right now is just undertaking the project or 
>rejecting the project.
>
>. . . . . . . . . . . . Ken


--
Upcoming public training: XSLT/XSL-FO Sep 10, UBL/code lists Oct 1
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 Jul'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal