[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ciq] Use of OASIS code list specs. in CIQ TC V3.0?
Hi David, Here is what the suggestion is: Our current approach in V3.0: - We have a separate schema for listing all the codes as enumeration values. Users need to create all the codelists in the schema that they want to use. It is a single schema file for all codelists. - The main payload schema (say, xAL.xsd, xNL.xsd) includes this codelist schema. - Users do not make any change to the main payload schema if they want to modify the codelist. They modify the schema codlist to do the changes. - Validation of the XML document generated is done in one pass (validation of the document against the main schema and the codelist schema) What has the codelist group done: - A two phase validation approach, first phase for validating the payload XML document and the next phase is to validate the codelist values used in the payload. I need to read it further to understand more about this. Below is the response from Ken Holman to my questions. From Ram: >Thanks very much! I had a quick look. What we are doing is: >1. Have all the codlists represented as separate schema >2. Include these codelist schema in the main payload schema. >This allows users to modify the separate code list schema to include >the codelist values (industry or their owns) without touching the >main payload schema. From Ken: But don't you have to touch the main payload schema in order to change your import statements? We worked towards a two-step approach so that the XSD schema files remain untouched and read-only from the published schemas from the committee. Not even import statement changes are needed. Not even XSD is needed! From Ram: >3. Validation of the payload schema for structure and syntax will be done >alone with validation of the codelist values From Ken: (I'm assuming you meant to say "along with" and not "alone with") Then you'll have to use something other then genericode ... it is not designed for validation. But you can maintain your information in genericode and then translate genericode into XSD for validation. Genericode is not a schema format ... it is an agnostic representation of a list of values. Some might use that list for validation, others might use that list for data entry. Still others might use it solely for documentation of item-level meta data. From Ram: >I am thinking of replacing the above approach by using the code list >representation schema of CodeList TC. From Ken: You've added the word "schema" where it does not apply ... the CLRTC is just for "Code List Representation". The genericode schema is for validating a representation of a code list, it is not a schema for validating XML documents that use code list values. Does this help? From Ram: >We do not want to go for 2 phased validation approach, From Ken: Why not? It uses W3C-standardized XSD and ISO-standardized Schematron as implemented in W3C-standardized XSLT. From Ram: >but just to include the CodeList schema as part of >our payload schema and do single pass validation. From Ken: Why is it important to do single-pass validation? We have come to the realization that value validation is managed separately than structural/lexical validation. Yes you can conflate the two, but then you have "disturbed" the XSD files with the modifications for values. From Ram: >We want to use codelist schema because it is a standard way of representing >codelists. From Ken: Right ... it is not a standard way of representing code list value validation ... just the code lists themselves. From Ram: >What do you think about this approach? From Ken: I think you may have misunderstood the objectives of the CLRTC. Users of our code lists might find them useful for validation of XML documents (as in UBL), but the CLRTC is only validating the code list representation, not the validation of XML documents using code-list-based information items. From Ram: >Can this be done? From Ken: Genericode files cannot be used in XSD schemas unless you choose to write a translation of a genericode file into an XSD schema fragment. From Ram: >Do you see any issues? From Ken: In your payload schema, if you have one information item that is used in two different document contexts (different element ancestry), what do you do if the set of codes applicable in one document context are different than the set of codes in the other document context? XSD global elements and types have document-wide scope. What if your business rules demand less-than-document-wide scope? Two-pass validation handles both situations, whereas global declarations in XSD schemas can only handle document-wide scope of code list definitions. From Ram: >Does the main payload schema require to follow UBL NDR? I guess not. From Ken: Correct, since value validation is separate from structural validation, there are no constraints or guidelines on the structural validation. It is entirely a separate pass. But, can you tell me why you think two-pass validation is unacceptable in your environment? Surely flexibility and the ability to formalize code lists in context as artefacts would trump any concerns that might be raised regarding performance. I hope this has helped clarify things, Ram. . . . . . . . . . . . . . . . Ken ---------------------------- I believe this codelist spec. will help users to plug in any codelists of our choice (e.g. existing codelists produced by UBL) without changing the payload schema. Please provide suggestions. Codelist spec. is available in the codelist TC. Regards, Ram David RR Webber (XML) wrote: > Ram, > > Sorry I don't get it! "Represent a codelist" - but not suggest ones? > I think everyone knows what a codelist is and what it contains - so > seems rather redundant busy work. What is the value add here? I'd > hate for people to think that the "representation" is an actual > codelist. That was the huge potential whammy I warned about before to > them. Production codelists need to be machine optimized - not > volumous bulky xml padding metadata heavy items. > > I'd rather point people at ISO and machine processable examples - than > top heavy metadata about codelists. > > Just my preference. > > We've seen way to many very bad XML practices become instutionalized > into production code because of this failure for people to see the > difference - and I hate to set this up to be another instance of > confusion. > > This stuff makes me nervous. Care needed! > > Thanks, DW > > "The way to be is to do" - Confucius (551-472 B.C.) > > > -------- Original Message -------- > Subject: Re: [ciq] Use of OASIS code list specs. in CIQ TC V3.0? > From: Ram Kumar <ram.kumar@oasis-open.org> > Date: Mon, April 16, 2007 5:05 pm > To: "David RR Webber (XML)" <david@drrw.info> > Cc: Max Voskob <max.voskob@paradise.net.nz>, "Bruehlmeier,David" > <david.bruehlmeier@sap.com>, David Bruehlmeier > <typo3@bruehlmeier.com>, > ciq@lists.oasis-open.org > > David, > > > > No, we do not want to tell then what codelists they can use. The > > suggestion is whether to use the XML schema provided > > by Code list group to "represent" the code lists. The codelists could be > > industry ones or specific ones of the users. But they > > should be represented using the codelist representation schema provided > > by Codelist group. This is my thought. A way of > > representing the codelists using an industry standard. > > > > Ram > > > > David RR Webber (XML) wrote: > > > Ram, > > > > > > So the idea is to suggest some codelists that can be used? E.g. the > > > ISO country codes and W3C language codes? > > > > > > So the use case is just "hinting" for implementers? > > > > > > DW > > > > > > "The way to be is to do" - Confucius (551-472 B.C.) > > > > > > > > > -------- Original Message -------- > > > Subject: Re: [ciq] Use of OASIS code list specs. in CIQ TC V3.0? > > > From: Ram Kumar <ram.kumar@oasis-open.org <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose>> > > > Date: Mon, April 16, 2007 4:39 pm > > > To: "David RR Webber (XML)" <david@drrw.info <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose>> > > > Cc: Ram Kumar <kumar.sydney@gmail.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose>>, Max Voskob > > > <max.voskob@paradise.net.nz <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose>>, "Bruehlmeier,David" > > > <david.bruehlmeier@sap.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose>>, David Bruehlmeier > > > <typo3@bruehlmeier.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose>>, ciq@lists.oasis-open.org <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> > > > > > > Right David. They do not describe the codelists (e.g. country > > codes, > > > etc...). > > > The define the metadata to use the codelists. So, I was > > wondering whether > > > we need to use this metadata schema in CIQ to ensure consistent > > use of > > > codelists by users. > > > > > > Regards, > > > > > > Ram > > > From San Diego, OASIS Symposium > > > > > > David RR Webber (XML) wrote: > > > > Ram, > > > > > > > > Now I'm confused. They explicitly say in their charter that > > they are > > > > NOT doing that. > > > > > > > > If this has been reversed - then its a very bad issue. > > > > > > > > I think this may be confusing here however. The schema may be > > to > > > > describe metadata about the codelists - NOT the actual codelists > > > > themselves. > > > > > > > > DW > > > > > > > > "The way to be is to do" - Confucius (551-472 B.C.) > > > > > > > > > > > > -------- Original Message -------- > > > > Subject: Re: [ciq] Use of OASIS code list specs. in CIQ TC > > V3.0? > > > > From: "Ram Kumar" <kumar.sydney@gmail.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>> > > > > Date: Mon, April 16, 2007 1:59 pm > > > > To: "David RR Webber (XML)" <david@drrw.info <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>> > > > > Cc: "Max Voskob" <max.voskob@paradise.net.nz <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>>, > > "Bruehlmeier,David" > > > > <david.bruehlmeier@sap.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>>, "David Bruehlmeier" > > > > <typo3@bruehlmeier.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>>, > > ciq@lists.oasis-open.org <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose> > > > > > > > > David, > > > > > > > > The code list TC have defined an XML schema to represent > > the code > > > > lists. This > > > > is what I was thinking about. > > > > > > > > Regards, > > > > > > > > Ram > > > > > > > > > > > > On 4/17/07, *David RR Webber (XML)* <david@drrw.info <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> > > <#Compose> > > > > <mailto:david@drrw.info <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>>> wrote: > > > > > > > > Ram, > > > > > > > > My understanding is that the codelists spec's are merely > > > > guidelines. There are NO formal XML formats. > > > > > > > > Therefore - in terms of CIQ schema - I'd say there is > > probably > > > > "no action needed". > > > > > > > > Notice however that implementers using CIQ may use > > codelists - > > > > typically ISO ones for country codes, language codes, and > > > > such, and then in-country postal authorities for ZIP and > > > > postal codes, etc. > > > > > > > > I believe that the OASIS code list spec's make > > reference to > > > > just such "authoritative domain sources" (as does > > OASIS BCM) - > > > > and hence - so long as CIQ is providing the means to > > support > > > > those - I'm not sure there is more to be done at this > > point - > > > > except note that the OASIS codelist guidelines can be > > > > referenced in support of CIQ. > > > > > > > > Certainly I'd not anticipate any schema changes for > > V3.0 CIQ. > > > > > > > > In OASIS CAM we have an <Extension> mechanism for > > handling > > > > codelists - and for the UBL samples of CAM templates we > > > > provide samples of various ISO and W3C codelist values > > lookups > > > > to illustrate the techniques. Those lookups are actually > > > > against the CIQ v2 schema content inside UBL of > > course! Same > > > > thing for OASIS EML and their CIQ imports. We could > > point > > > > people at those UBL examples for samples of using > > codelists > > > > and CIQ - > > http://xml.coverpages.org/freeb-ubl-Announce.html > > > > > > > > Cheers, DW > > > > > > > > "The way to be is to do" - Confucius (551-472 B.C.) > > > > > > > > > > > > > > > > -------- Original Message -------- > > > > Subject: [ciq] Use of OASIS code list specs. in > > CIQ TC > > > V3.0? > > > > From: "Ram Kumar" < kumar.sydney@gmail.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose> > > > > <mailto:kumar.sydney@gmail.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>>> > > > > Date: Mon, April 16, 2007 12:31 pm > > > > To: ciq@lists.oasis-open.org <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose> > > > <mailto:ciq@lists.oasis-open.org <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>> > > > > Cc: "Max Voskob" <max.voskob@paradise.net.nz <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> > > <#Compose> > > > > <mailto:max.voskob@paradise.net.nz <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>>>, > > "James Bryce Clark" > > > > < jamie.clark@oasis-open.org <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose> > > > > <mailto:jamie.clark@oasis-open.org <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>>>, > > "Mary McRae" > > > > <mary.mcrae@oasis-open.org <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose> > > > > <mailto:mary.mcrae@oasis-open.org <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>>>, > > "Bruehlmeier, David" > > > > <david.bruehlmeier@sap.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose> > > > > <mailto:david.bruehlmeier@sap.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>>>, > > "David Bruehlmeier" > > > > < typo3@bruehlmeier.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose> > > <mailto:typo3@bruehlmeier.com <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose>>> > > > > > > > > CIQ TC, > > > > > > > > Just wondering whether we should implement OASIS > > CODE LIST > > > > V1.0 specs (to be released in May 2007) > > > > as part of V3.0 CIQ Specs given that we have not yet > > > > released V3.0 for public review. > > > > > > > > Please let me know your views > > > > > > > > Regards, > > > > > > > > Ram > > > > Chair > > > > > > > > > > > > > > -- > > > Ram Kumar > > > Manager - Technical Committee Development > > > OASIS > > > Post Office Box 455 > > > Billerica,MA 0821 > > > USA > > > +61 412 758 025 (Direct) > > > + 1 978 667 5115 (OASIS HQ) > > > + 1 978 667 5114 (Fax) > > > ram.kumar@oasis-open.org <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> <#Compose> > > > http://www.oasis-open.org <http://www.oasis-open.org/> <http://www.oasis-open.org/> > > > "Advancing e-Business Standards Since 1993" > > > > > > > > > > > > > -- > > Ram Kumar > > Manager - Technical Committee Development > > OASIS > > Post Office Box 455 > > Billerica,MA 0821 > > USA > > +61 412 758 025 (Direct) > > + 1 978 667 5115 (OASIS HQ) > > + 1 978 667 5114 (Fax) > > ram.kumar@oasis-open.org <http://email.secureserver.net/pcompose.php?aEmlPart=0&type=replyall&folder=INBOX&uid=103405#Compose> > > http://www.oasis-open.org <http://www.oasis-open.org/> > > "Advancing e-Business Standards Since 1993" > > > > > -- Ram Kumar Manager - Technical Committee Development OASIS Post Office Box 455 Billerica,MA 0821 USA +61 412 758 025 (Direct) + 1 978 667 5115 (OASIS HQ) + 1 978 667 5114 (Fax) ram.kumar@oasis-open.org http://www.oasis-open.org "Advancing e-Business Standards Since 1993"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]