Re: [ubl-clsc] URI approach to code list metadata

[jon.bosak@sun.com]

In preparation for this afternoon's discussion, I wanted to set
forth the reasons that I don't agree with the solution proposed by
Stephen Green (even though I strongly sympathize with his reasons
for proposing it).

As I understand Stephen's position from the discussion Monday, he
wants the code list metadata (or at least the most essential
pieces of it) to be located as close as possible to the use of a
code list item.  In the case where the code value is given in an
attribute, an example might look something like this:

(1) <amount currency='CAD'>123.45</amount>

(I've used CAD instead of USD for reasons that will be apparent
shortly.  It should be understood here and throughout that I am
making up the element and attribute names as I go and that this is
not intended to perfectly represent the current schemas.)

Suppose that the currency list is being maintained by BSI.  Then
to make the authority as clear as it possibly can be, we might
have this:

(2) <amount currency='CAD' agency='BSI'>123.45</amount>

I have two problems with this approach, one practical and the
other conceptual.

The practical problem is that we cannot use this mechanism to
attach two codes to a single value.  Suppose, for example, that
there is a locale code list maintained by LISA, and two values on
that list are "can-fr" (meaning Quebec) and "can-en" (meaning the
rest of Canada).  I need this information in order to place the
dollar sign when formatting.  So now we have:

(3) <amount currency='CAD' agency='BSI' 
            locale='can-fr' agency='LISA'>123.45</amount>

Clearly we have a problem now with the agency attribute.  (Yes,
this is not how we would probably want to handle locales, but I
can't think of a better simple example right now.  I feel quite
certain that we will encounter real cases that better illustrate
this point.)  We could probably figure out some way around the
problem in the particular case, but it's intuitively clear to me
that this approach is fraught with difficulty if we want to attach
more than one code to a particular element content.  The root of
the problem is that there is no simple way in XML to group or
associate attributes with each other.

This leads me to what I see as the conceptual problem.

The whole element/attribute distinction in XML inherits a
framework dating back to Aristotle that conceives the world in
terms of "things" on the one hand and "attributes" (or properties
or qualities or characteristics) of things on the other.  Thus, if
I have a red book, the thing is "book," and one of its attributes
(or properties or qualities or characteristics) is "redness."

Obviously this distinction is artificial, but in fact all
distinctions are artificial, and this is the one we've been given
in Western culture to work with.  In particular, it is the one
that is native to XML.

So if I have a monetary amount of CAD 123.45, then the thing is
the quantity 123.45, and one of its attributes (or properties or
qualities or characteristics) that distinguishes it from other
amounts of 123.45 is the fact that it is an amount in Canadian
dollars.  This leads to the form seen at (1), which is idiomatic
in XML at a very basic level.

The conceptual problem I have with (2) is that it breaks this
conceptual model.  "CAD" is an attribute of "123.45", but "BSI" is
not; it is an attribute (or property or quality or characteristic)
of "CAD".  And there is nothing in the structure of XML itself to
make this association; that has to be done entirely out of band.

I share Eve's and Bill's misgivings about stashing all the
metadata into URN fields, and that's something we will have to
discuss further.  But it appears to me that the URI method is a
far cleaner way to deal the two problems I have outlined above.

Jon