[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Genericode feedback and the relationship to CCTS CodeType
Hello, Through collaboration with fellow OAGi architects I came across the genericode work. I think this is an important topic from the perspective of standardizing code set representation such that it can be used in XML instance validation, even if it requires 2 pass validation or alternative validation beyond Schema. I can only imagine in the future there is potential for this functionality being built into parsers/tools, much like some do now for Schematron. So considering industry standards have adopted CCTS with the associated CodeList attributes there is opportunity to validate XML instance documents based on these attributes and their relationship to genericode representations of the code set. To understand the feasibility of such a solution, consider a practical application based on Stylesheets and Schematron. An example solution might be: · Decide on a code set and represent that in genericode (e.g. CountryGenericodes.xml) · Choose names for the code set and use both in the genericode instance and the CCTS based XML instance that will be validated. · This requires a mapping between genericode elements to CCTS CodeListType attributes, for example using the OAGi representation of a CodeType: o oa:Code/@listName === /gc:CodeList/Identification/ShortName o oa:Code/@listID ??? /gc:CodeList/Identification/LongName[@Identifier="listID"] § This is where the examples put ISO3166-1 in the genericode documentation? o oa:Code/@listURI === /gc:CodeList/Identification/LocationUri o oa:Code/@listSchemeURI === this would be the genericode schema location o oa:Code/@listAgencyName === /gc:CodeList/Identification/Agency/LongName o oa:Code/@listAgencyID === /gc:CodeList/Identification/Agency/Identifier o oa:Code/@listVersionID === /gc:CodeList/Identification/CanonicalVersionUri · Validate instances for each occurrence of a Code element in a context such as oa:Classification/oa:Codes: o oa:Code/@name look up using XPath § document(oa:Code/@listURI)/gc:CodeList/SimpleCodeList/Row/Value/[@ColumnRef= "name"]/SimpleValue o oa:Code look up using XPath: § document(oa:Code/@listURI)/gc:CodeList/SimpleCodeList/Row/Value/[@ColumnRef= "code"]/SimpleValue o Verify the Code and the Code/@name exist and are in the same Row. Validation success or failure. This demonstrates the concept behind my idea (probably not original) of using BOD instance Code attributes to identify an external Code Set XML instance document that is used to validate the content. This would be a consistent design approach that could be used for any “standard” CCTS and genericode based solution. It could also be easily coded in Schematron as an abstract rule. What I don’t like about the genericode solution is: 1. The apparent disregard for semantic naming alignment with CCTS CodeType attributes, why not align them more directly? 2. The open content needed to represent the name and code in the Row/Value, why isn’t this a semantically named element? 3. No place for the @listID, it’s done using open content in an Identification/LongName with an @Identifier set to “listID”. At least that is how the examples in “Code List Representation (Genericode) Version 1.0” did it. This seems like such an important concept that it should be explicit with a semantically named element or attribute. Apart from that, I think it’s good that there is work on standardizing how to represent a Code Set but it really needs to be aligned with the CCTS work to ensure it can be used in real world situations. Best Regards, Kurt Kanaskie Independent XML Consultant OAGi Member kurtk@ptd.net
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]