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

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

At 2007-08-24 16:17 +0100, Anthony B. Coates (Miley Watts) wrote:
>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.

Then references to it could be moved to an informative annex 
regarding the implementation of the supplied stylesheet modules.

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

Granted, but the methodology is specifically geared to work with the 
standardized representation we have come up with.  It makes, in my 
mind, a logical companion document.

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

I take your point and perhaps moving references to it to an 
informative implementation annex would satisfy your concerns.

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

I'm not so sure.  The *normative* parts would be within the scope of 
the TC, I don't see a problem with informative parts touching on other areas.

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

Granted.

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

Agreed ... but I'm thinking of specs like Schematron where there are 
informative annexes regarding implementation and example use.

I have fully bought into your observation that I've conflated the two 
in the existing document.

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

Granted.  Another opportunity to use an informative annex 
illustrating the context.

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

Granted.  And an excellent example to use in another informative annex.

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

Points all taken ... but I would like to keep it all in a single document.

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

Let me try and take a stab at reorganizing normative and informative 
content to address your concerns.

This has been excellent feedback.

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