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

 


Help: OASIS Mailing Lists Help | MarkMail Help

codelist-comment message

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