Re: "CODE" representation class

[Martin Bryan <mtbryan@sgml.u-net.com>]

Dwight


> In San Jose, we discussed a set of standard representation classes for core
> components. One of them was, "Code" where (if I understood correctly)
> concepts like "Country Code" or "currency Code" would make use of this
> representation class.
> 
> Trying to use Martin's forms to record this, we find that I cannot create an
> entity "currency code" with representation class "code" where the entity
> defined "ISO standard xxxx" as the definitive enumeration of acceptable
> values.

Let me start to answer you confusion by checking that you have not made a basic mistake. The ISO 3166 code set defines a set of specific values, expressed as 2 or 3 capital letters, that can be used to identify different countries. The set of permitted values is defined as a code set in the current forms. Similarly the ISO 4137 currency codes are defined as a code set of three (capital) character alphanumeric "codes". The mythical "generic class" of code is a data type, not a code list. For ISO 4137 this constraint on permitted values can be defined, for example, as 3 capital alpha characters (e.g. [A-Z]{3}) in the data type definition section of the code set form. I have required the constraint to be recorded in this way to avoid the need to define the datatype for the code set on a different form from the code set definition, with some type of link between them

> Rather, we find a need to define "currency code" as a representation class
> invoking the ISO standard, and then define some other entity (e.g. monetary
> amount) as represented by the currency code representation.

Now lets try to tackle this problem. There are two aspects to it. Firstly is the currency code a separate field of information, or a qualification for a numeric field? For example, do we want the XML to read 
<Amount><Currency>GBP</Currency><Value>123.45</Value></Amount> 
or 
<Amount currency="GBP">123.45</Amount>?

The first case is easy to deal with, and I trust understand, using the forms. There is an Data Entity called Amount that has two subentities, Currency and Value, the first of which points to a code set of permitted currency codes and the second of which points to a data type for decimal figures with two decimal places.

The second case is harder to understand how to deal with using the forms for the simple reason that the forms are generic in nature, and deliberately do not define whether the leaf nodes should be treated as elements or attributes. As far as the forms are concerned the definition for this version is identical to that for the previous version: the decision to make one of the leaf nodes an attribute and the other the contents of the containing entity rather than using embedded elements within the XML is something that must be done at a later stage than the "syntax-neutral" capture of the information about the core components that these forms are designed to provide for.
 
> Either
> 
> - our list of representation classes was wrong, and should include things
> like "currency code" and "country code" rather than "code"

Your list of representation classes was wrong. Code is a bogus representation class. What is actually required is a data type that constrains the values permitted in a concrete code list, not a generic representation class that says codes must be alphanumeric. (I argued strongly against the inclusion of Code in the generic list in Brussels for just this reason.)
> 
> or else
> 
> - the forms are wrong, and should allow codeset to be specified within the
> entity definition rather than the representation class

The code sets cannot be "specified within the entity definition". The most that could be expected is that the constraints column of the entity definition allows reference to the relevant code set and an associated data type. But even this would be wrong. The code set is really the main thing, its data type being a subsidiary restriction on the definition of the code set, not on the definition of the entity. This is the way the forms are currently constructed. 

What is perhaps required is a column that allowed users to say whether or not a particular code set or data representation should be treated as an embedded element or as a qualifying attribute, but if I add this will the definitions we capture continue to be syntax independent? 

> or else
> 
> - I am confused again, please straighten me out?

Hopefully I've managed to remove the confusion, but if not do not hesitate to ask again. The real question you must keep asking yourself is whether a representation is a "fundamental" one or a "derived" one. It is essential to get at the fundamental representations before completing the entity definitions.

One final thought. The set of code sets defined using the Code Set forms automatically defines the generic "Code" object that you seem to want to hard code into a Core Components representation definition.

Martin