[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Candidate decision regarding code list support publishing
In today's face-to-face we spent a good part of the afternoon talking
about the new additional code list resources and the code list revision policy.
To prepare to make decisions, this post summarizes where I think we
reached in our discussions. We will decide on this later on during the week.
(1) - I have prepared context/value association files used to
recreate the and I have published these to the Kavi directory, but
during the meeting I did not remember that these actually have been
published; they can be found here:
http://www.oasis-open.org/committees/document.php?document_id=23531
(2) - the code list support files will be more useful if they are
posted to the UBL docs repository, since their relative XPath
addresses can point to the actual code lists
- these support files are not for all users of UBL, and in fact are
not for many users of UBL ... most users will be using either
defaultCodeList.xsl or the XSLT stylesheet that users of the support
files create for their use
(3) - as new code lists are produced, it makes sense to publish these
lists and their support files as subdirectories of the UBL docs
repository so that at any time a developer can download from the
repository *all* versions of *all* code lists in the UBL history so
that a developer can create their own context/value association files
- it is not necessary to duplicate the publishing of unchanged
lists since all of the subdirectories are in the UBL docs repository
- for any support release of new code lists there will be a new
version of defaultCodeList.xsl published so that UBL users can always
obtain the latest default second-pass validation without having to
use the methodology to make it
- there is currently a UBL 2.0 code list directory:
http://docs.oasis-open.org/ubl/os-UBL-2.0/cl/
- two of those code list files are the country code list and the
transportation status code list:
http://docs.oasis-open.org/ubl/os-UBL-2.0/cl/gc/default/CountryIdentificationCode-2.0.gc
http://docs.oasis-open.org/ubl/os-UBL-2.0/cl/gc/default/TransportationStatusCode-2.0.gc
- there is a fault in the country identification code list for
Bosnia, so we should publish a repaired version as an erratum
- say we decided to publish a new code list support package in
February 2007 (a past date for illustration purposes) for the erratum
... we would have the new code list, the new context/value
association file that overrides the old context-value association
file, and the new resulting defaultCodeList.xsl in a revision subdirectory:
http://docs.oasis-open.org/ubl/cl-200702/gc/default/CountryIdentificationCode-2.0.gc
http://docs.oasis-open.org/ubl/cl-200702/cva/defaultCodeList.cva
http://docs.oasis-open.org/ubl/cl-200702/defaultCodeList.xsl
http://docs.oasis-open.org/ubl/cl-200702.zip
- following that date there might be a new transportation status list
(the current version is "Third Revision", the next version we might
want to call "4" to use numbers instead of words for the meta data)
that has new values
- say we decided to publish a new code list support package in March
2007 for the addition ... this would again have the required support
files, a new context/value association file that *supplements* (not
overrides) the old context-value association file, and the new
resulting defaultCodeList.xsl in a revision subdirectory:
http://docs.oasis-open.org/ubl/cl-200703/gc/default/TransportationStatusCode-2.0.gc
http://docs.oasis-open.org/ubl/cl-200703/cva/defaultCodeList.cva
http://docs.oasis-open.org/ubl/cl-200703/defaultCodeList.xsl
http://docs.oasis-open.org/ubl/cl-200703.zip
- note that the cl-200703.zip file would contain the cl-200702 and
cl-200703 directories, such that a developer need only download the
latest ZIP file to get *all* of the code list directories since the
publishing of os-UBL-2.0 ... this way each dated directory need only
have the changed files and not all files
- in the above examples we would not be limited to only changing one
list at a time: any time we publish a new code list dated directory,
it would contain all of the changes for that date
- users wanting the latest defaultCodeList.xsl just goes to the
latest dated subdirectory and obtain their file ... nothing else is
needed for them to get default second-pass validation
- developers wanting the latest materials to make the latest
defaultCodeList.xsl would download the latest ZIP file and the
os-UBL-2.0.zip package ... unzipping both of these in their
development directories ensures the relative paths are all correct
In preparing this I have these questions we need to answer:
(Q1) - when do we set this up and get started?
- genericode 1.0 is about to go to Public Review
- the methodology will be finalized at 1.0 only after
genericode 1.0 is finalized
- should we wait to set all this support stuff up once both are
finalized at 1.0?
(Q2) - how often do we publish the code list directory?
- perhaps we can schedule new code list directories every 6
months (4 months?) from December 2007 which should give us the time
to shake out the approach before then and it is on the first
anniversary of the specification's release
(Q3) - does it make sense for a developer to find everything in the
latest ZIP file, or should the above be changed such that there is no
duplication and each ZIP directory has only the files in that
directory: this makes more downloads for the developer, but for the
developer who is following development step by step they only
download the latest and unpacking it won't overwrite any of their
existing files ... the more I think about it, the more I think each
ZIP file should only have the files of that directory
(Q4) - note that the genericode filenames used above are ambiguous
... is this a problem? The files are distinguished by the
subdirectories in which they are found, and by the meta data found
therein ... do we need to go the extra step of distinguishing the
file names, and if so, how do we do this in a consistent fashion? My
gut feel is that we do not and that directory context is enough ...
if a file is found out of context, the contents reveal the meta data
My initial assessment is that all of the above is achievable and will
mechanically work, but is it too complicated? I think not since we
will always have a simple defaultCodeList.xsl that anyone can
download with all of the hard work done. Anyone who needs to use the
validation methodology will already be familiar with how the
methodology works. Having these files in multiple directories
shouldn't scare them off since all of the relative directories work.
Thanks to everyone for their input at today's meeting ... it was very
productive and the questions were very astute.
. . . . . . . . . . . . . Ken
--
Upcoming hands-on training(Europe 2007): XSL-FO Jun 11; UBL Oct 01
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 Aug'05 http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]