OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

codelist message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: A formal comment received by the CLRTC


A comment has been posted to the CLRTC comment list:

   http://lists.oasis-open.org/archives/codelist-comment/200610/msg00000.html

I have added this to the agenda for tomorrow's meeting for discussion.

My read is that the comment focuses as if the 
code list representation we are creating for 
interchange is being used for direct real-time implementation.

An implementation would not (should not) base 
real-time process-critical activities on 
interchange representations that are designed for 
documentary and semantic uses.

The genericode representation is designed to 
communicate and manage the information maintained 
for a code list, it is not designed to be used 
directly in any validation process or, in fact, 
any process whatsoever, so it is designed with 
representation objectives and not processing objectives.

Note that in UBL the genericode format is not 
accessed in real time for validation purposes: 
the code list file is transformed a priori into a 
Schematron expression that, itself, is 
transformed a priori into an XSLT stylesheet that 
is used for real-time validation purposes and is, 
in fact, unencumbered by all of the very 
necessary representation overhead needed for 
interchange that is not needed for validation.

The comment also makes reference to (paraphrased) 
"minimal XML knowledge for tools and processing 
mechanisms".  Again, what an implementation does 
with the information expressed in the 
representation used for interchange is up to the 
implementation and totally out of the scope of 
the committee.  We are necessarily using XML for 
the interchange objectives of platform independence.

The comment makes reference to code list actions 
of "create, support and maintain".  Again, the 
processes and mechanisms used by anyone to author 
and maintain a code list (editing, database, 
machine processing, Ouija board, etc.) are 
outside the scope of the *interchange* format we 
are creating for code list representation.

Lastly, I distill a comment about registration 
authorities ... again, not under our purview ... 
we hope that new and existing registration 
authorities value what we produce as a work 
product so that they make the information the 
create and maintain available in a portable and 
standardized interchange format for 
representation, but we aren't about to get into the business ourselves.

I don't think I've missed anything else ... can anyone see anything?

I appreciate that a comment like this has 
arrived, so that by addressing it, we might bring 
these issues to light for others who might have 
the same thoughts and perspective.

Any thoughts from others?  I would like to craft 
the essence of a committee response during the meeting.

Thanks!

. . . . . . . . . . . Ken

--
UBL/XSLT/XSL-FO training: Allerød/Vårø Denmark 2006-11-13,17,20/24
UBL International 2006  2006-11-13/17 http://www.ublconference.com
World-wide corporate, govt. & user group UBL, XSL, & XML 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]