[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]