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

["Anthony B. Coates (Miley Watts)" <abcoates@mileywatts.com>]

Comments below.

On Fri, 24 Aug 2007 01:08:18 +0100, G. Ken Holman  
<gkholman@CraneSoftwrights.com> wrote:

>>> 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.

It's not a critically important component, since you could release the  
methodology without it, and it would still be useful.  That said, I agree  
with you that the constraint checking is potentially very useful, and it  
does weaken the methodology to remove it.

However, it has to be remembered that this is the Code List Representation  
Technical Committee, and OASIS was very specific in the choice of this  
name; we are not, remember, the "Code List Technical Committee", because  
that would have been too broad a scope.  I don't have any problem with the  
methodology in itself, but I do think that this TC is at best limited to  
releasing items that relate specifically to code list representations.   
Value checking that is unrelated to code lists strikes me as being  
completely out of scope.

Historically, I was keen the genericode not be seen as part of UBL, not  
only because it was developed independently of UBL, but also because it  
clearly had applicability beyond the scope of UBL.  The same is true of  
this methodology, but the methodology as written is not only beyond the  
scope of UBL, but some parts of it are also beyond the scope of the CLRTC,  
I would suggest.  This is not a criticism of the methodology, it's more to  
do with whether it is appropriate for TCs to publish specifications that  
are not within the scope of the TC, or go beyond the scope of the TC.  I  
think we have an issue like that here.

>> 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.

The thing is, isn't that mixing implementation with specification?  I  
don't see any problem if your implementation provides extra features  
beyond those that might be part of a CLRTC specification.  However, I  
don't think that we should be defining the scope of our work by what  
particular implementations may be capable of doing.

>>> 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.

Well, the UBL history of the document strikes you throughout the document  
as you read it (since UBL is the only and frequent example), and to me the  
language was somewhat confusing, since the methodology is clearly just as  
appropriate when used within a single organisation where there is no  
concept of trading partners and such.  It has to be remembered that while  
we have great hopes for UBL, it isn't yet widely enough used that you can  
use it as an "everyday" example in the way that you could XHTML, for  
example.  Many potential users of the methodology, probably the majority,  
won't have experience of UBL.

One could write a document that is focussed on UBL, for the benefit of UBL  
users, but there needs to be something that doesn't assume any particular  
knowledge of a particular XML format, what it is for, and how it is used.

>>> 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.

Sure.  I didn't want to launch into a line-by-line critique of the  
document at this early stage.  I could offer to co-edit to look  
specifically at readability issues, if that would be a help.

Cheers, Tony.
-- 
Anthony B. Coates
Senior Partner
Miley Watts LLP
Experts In Data
UK: +44 (20) 8816 7700, US: +1 (239) 344 7700
Mobile/Cell: +44 (79) 0543 9026
Data standards participant: genericode, ISO 20022 (ISO 15022 XML),  
UN/CEFACT, MDDL, FpML, UBL.
http://www.mileywatts.com/