RE: [ubl-dev] cva2xsl script

["Lists DMS" <lists@d-m-s.co.nz>]

Hi Daniel,

We have been using the cva2xsl scripts for several years, including various
releases of gc and cva versions, and we never experienced a bottleneck or a
feeling of unease about using the scripts.

Regards
Juerg
www.d-m-s.co.nz


> -----Original Message-----
> From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
> Sent: Monday, 9 January 2012 3:25 p.m.
> To: ubl-dev@lists.oasis-open.org
> Subject: Re: [ubl-dev] cva2xsl script
> 
> At 2012-01-09 00:43 +0100, Daniel Orasanu wrote:
> >I have (again) a few questions:
> 
> All questions are welcome!
> 
> >Mr. Holman wrote in an Email:
> 
> "Ken" please (though now we have a plethora of Ken's on the TC
membership!).
> 
> >".
> >
> >When thinking last week about an upcoming code list task at UN/CEFACT,
> >I was reminded of arguments raised during a similar development process
> >in the OASIS Code List Representation Technical Committee: that the TC
> >should *not* be in the business of publishing running executable code
> >in support of its standards. The two main arguments are:
> >
> >(1) - who is going to maintain the code if it breaks and the author is
> >no longer on the committee?
> >
> >(2) - the TC should not be in competition with any organization that
> >may wish to write code to fulfill the same requirements
> >
> >One of the arguments for producing code was "but this is a reference
> >implementation" and that was deemed insufficient to address the two
> >concerns.
> >
> >The case study is the CVA to Schematron conversion tool that I wrote,
> >donated to OASIS, and then repatriated back to Crane because of the
> >committee decision:
> >
> ><http://www.CraneSoftwrights.com/resources/ubl/#cva2sch>http://www.Cran
> >eSoftwrights.com/resources/ubl/#cva2sch
> >
> >
> >
> >
> >.."
> >
> >Here my Questions:
> >
> >1)      He spoke about "..because of the
> >committee decision.." is there any UBL TC official decision why the
> >script went back to Crane Softwrights Ltd.?
> 
> The decision did not happen in the UBL TC but in the Code List
Representation
> TC.  I wrote the first implemented version of what was then called
> "Schematron-based Value Validation Using Genericode" and there were
> preliminary implementations of the process posted to the OASIS repository
as
> part of the specification development.
> 
> This was the discussion that triggered the change from the specification
of a
> validation process to the specification of a file format:
> 
> http://lists.oasis-open.org/archives/codelist/200708/msg00023.html
> 
> Within two months, in the minutes of the October 9, 2007 meeting, the
> deemphasis of the process and the emphasis of the file format was minuted:
> 
> http://www.oasis-open.org/committees/download.php/25622/Meeting-20071009-
> Minutes.htm
> 
> The specification ended up with the name "Context/Value Association" for
the
> file format, with no implication of any process stuff.
> 
> I then repatriated the code and put it in Crane's free resources.  It was
> available to all when in the OASIS repository, my updates have also been
made
> available to all.
> 
> >2)       "..the TC should *not* be in the
> >business of publishing running executable code in support of its
> >standards..". The script above is such an executable.
> 
> Right, which is what the Code List Representation Technical Committee did
not
> want to see as part of the specification.
> 
> >How do I have to understand this script:
> >
> >a.       The script is free to use
> >
> >b.      AND  it is property of Crane Softwrights Ltd.
> >
> >c.       WHAT IF CraneSoftwrights decides not to
> >update this script on further UBL/CVA/Genericode features ?
> 
> The license allows the source code to be modified by others for any
purpose.
> 
> >  - this is pure hypothetical-no affront to Crane Softwrights Ltd. J.
> > Isn't this a kind of "bottle neck" for the script and for the
> > UBL-Validation?
> 
> No-one has come to the Code List Representation TC requesting any changes
to
> either genericode or CVA file formats, so I don't see a bottle-neck.
There is
> *plenty* of time for alternative implementations of the process to be
created
> by others if Crane's are deemed insufficient.
> 
> >I see  this script as the linking-piece between UBL , CVA ,GC Files and
> >validation process.
> 
> These scripts are being used by the committee in order to produce the
> committee deliverables.  A snapshot of the scripts are posted for archive
in
> the TC repository (admittedly these are old; there was discussion recently
> with the editors that I should refresh the snapshot).  If Crane ever shuts
> down unexpectedly, the other TC editors have access to everything that is
> needed.
> 
> >Are any other (known | free | not-free) scripts who do the same job?
> 
> Not that I know of.
> 
> The CLR-Dev list (the equivalent of this list but for the Code List
> Representation TC) is very quiet:
> 
>    http://lists.oasis-open.org/archives/clr-dev/
> 
> No-one there has expressed any interest in developing an alternative.
> 
> >3)      Can this script information be mentioned
> >in future UBL 2.1 documentation?
> 
> The specifications are mentioned, which should be sufficient.  There is no
> requirement to use Crane's code and I would not want it implied that it
might
> be a requirement.
> 
> I'm not sure where the concerns are.  There should be by now enough copies
of
> Crane's material out in the wild that if Crane were to disappear the TC
would
> not be prevented from producing its deliverables.  Is that the nature of
your
> concern?
> 
> I hope this reply has helped.
> 
> . . . . . . . . . . . . . Ken
> 
> 
> --
> Contact us for world-wide XML consulting and instructor-led training Free
5-
> hour video lecture: XSLT/XPath 1.0 & 2.0 http://ude.my/uoui9h
> Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/u/
> G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
> Google+ profile: https://plus.google.com/116832879756988317389/about
> Legal business disclaimers:    http://www.CraneSoftwrights.com/legal
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org