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:46 +0100, G. Ken Holman
><gkholman@CraneSoftwrights.com> wrote:
>
>>>At 2007-08-19 17:10 +0100, Anthony B. Coates (Miley Watts) wrote:
>>>>PS  Is there any intention that any part of this document would be
>>>>normative?  That wasn't obvious.  Thanks,
>>>
>>>I was expecting to take it to OASIS Standard status as we are doing
>>>with genericode.  That way those who choose to use this approach with
>>>genericode can have an OASIS standard to work with.
>
>Yes, but what would be the value in having an OASIS standard for the
>methodology?  I mean that as a serious question, what would be the actual
>realisable value beyond the value already provided by publishing it and
>making it available?

The context/value association file is an XML vocabulary and I think 
it deserves a normative standardized status so that organizations 
such as the Ministry of Education of New Zealand can cite it as an 
OASIS standard.

I see stopping at a Committee Specification as something akin to an 
ISO Technical Report, whereas an OASIS standard would be akin to an 
ISO standard.  I think the normative part of this specification 
should be an ISO standard.  I'd like to keep the informative part in 
an annex, but if that isn't considered acceptable to the committee as 
a whole, it could be a separate technical report as a committee 
specification.  But I'd prefer keeping all the information in a single source.

>There are some parts of the methodology that I think would be useful to
>standardise, like the XML used to map document contexts (XPaths) to
>particular code lists.

Right ... that's the context/value association file.

>That potentially has broader application than just
>this methodology, since it could be used by non-Schematron implementations
>as well.  Other parts of the document strike me more as "good practice"
>guidelines that should be published, but don't necessarily need to be a
>standard, since (to me) there is no obvious conformance requirement, i.e.
>no obvious requirement for all business partners to achieve the same
>effect in exactly the same way.

Granted ... and as noted in my other response that following examples 
of other specifications this could easily be relegated to an 
informative annex.  Especially considering your example of using 
XHTML as an example document needing code lists.

>Indeed, some of the document seems to describe a particular
>implementation, and I can see that other implementations could potentially
>achieve the same result.

Only below the point of using Schematron ... an implementation note 
in an informative annex regarding the supplied demonstrative (and 
production-ready) stylesheets would address this.

>In that case, I myself would prefer that we
>avoid normatively publishing items that unduly contrain implementations
>without our having a particular business reason for doing so.
>
>So I did mean this as a serious question, and I would be looking for the
>TC to make a decision on what parts of the proposal should or should not
>be normative and taken to OASIS Standard status.  As with my previous
>post, this is not about the usefulness or usability of the methodology, it
>is about what is appropriate procedurally for the TC and OASIS.

I totally agree.  But I just don't want to fragment the source of the 
information.  A restructuring should (in my mind) address your concerns.

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