Using The CC Tool

["Lisa M. Shreve" <lms@wwnet.com>]

Hi All,

I hope this message finds all of you well.  As for myself, a busy summer
is coming to an end and a busy fall is starting up.

I received a couple of weeks ago, a message from a fellow CC member, who
was having difficulty using the CC forms.  I received an excellent
response to his questions from Martin.  So, I'm passing this along.

Have a great day,

lms

---

• From: "Martin Bryan" <mtbryan@sgml.u-net.com>
• To: "Dwight Arthur" <darthur@bestweb.net>
• Date: Wed, 13 Sep 2000 08:58:50 +0100

Dwight
> 
> All of this makes a certain degree of theoretical sense but it's not
> compatible with the concepts behind Hisano's methodology and Martin's forms.

What you were using in San Jose were the detailed forms, which defined Data Formats and Code Sets, which were in shown at the uppermost level in the model, but were not based on Hisanao's model inside as they went further to allow the definition of formats other than those previously defined as representation classes. (Just for people like you with special requirements!)

Note the title of the recently released new data representation form - its for defining SIMPLE data types, not complex ones of the type you are discussing. 

> Following the concepts we pursued with Sue, I should now try to define a
> representation class "price" composed of a code and another representation
> class (monetary amount) and I should then define the monetary amount
> representation class as a code and a quantity.

The concept of Amount used in the Simple form is undefined at present. It is presumed to have some mechanism whereby a decimal value is associated with a set of valid currency codes based on ISO 4217. The formal definition of this will have to be done using the full version of the datatype form (DataFormat.htm) where it will be defined using patterns and/or in the form of an XML Schema data type definition that requires a decimal value to be accompanied one of a relevant set of strings.

All of the "simple datatypes" listed in the Simple form need to be formally defined in this way. The list in the form is not considered (by me at least) to be complete: it is a starter set, and we will add other entries if requested. (I have never bought into Hisanao's original concept here, and will continue to fight against any proposal that there is a fixed set of datatypes that is relevant for EDI because it is blatantly not true.)

> However, the form for a
> representation class does not allow me to use other representation classes
> in the definition. 

The Simple form does not - it only allows simple definitions. The DataFormat form allows you to define any complexity of basic dataytpe that is definable using XML Schemas, and provides a text box where you can define anything that you cannot define yourself so that we can capture the requirements and then have an expert evaluate how best these can be met.

You should remember, Dwight, that the XSL Schema definition will allow you to embed an enumerated code set within a data definition. The fact that this cannot be captured simply using the existing forms (other than by writing a formal schema definition in the Definition of Formatting Constraints area) is beside the point. The forms, obviously, have their limitations at present. (If someone wants to put up the money for the programmers we might be able to create the all-singing software for capturing all requirements, but don't expect such a beastie for free - I have other things to do in my "spare" time.) 

> My choices are code sets and data formats. The fact that
> code sets have a form of their own seems to rule out any attempt to create a
> form that defines what a code is in terms of a representation class. 

Not necessarily. Remember that CodeSet.htm also allows you to define a data format to be defined. At present this is envisaged as constraining the form of each of the code set entries, but like you I can envisage "variants" of this requirement. However, the idea is that there should be a code list for ISO 4217 country codes, and that the results of this code set could be "copied" into the definition of the Amount data type as part of its definition. At present we have not defined a mechanism for doing this, and XML Schemas do not provide a general mechanism for doing it other than entity definitions. I see no technical reason why it cannot be done, but see no easy way of creating a form for recording this information until such time as the basic datatypes are defined in a referencable registry. However, once again I must remind you that there is a limit to the amount of time I can spend adding functionality, and that there is a limit to how much processing IE5 can do without running out of memory (which is 

>Also,
> the data format is itself defined in terms of "basic data types" such as
> "date only" "time only" "date and time" "duration" and "Boolean value" which
> seem to correspond pretty closely to Sue's representation classes "date"
> "time" "date-time" "duration" and "indicator".

Not sure what you are getting at here? Are you suggesting there are further missing entries in the list of datatype provided in the Simple form? (What is an indicator?)

> In order to define the price on Martin's forms I found that I should create
> a data representation consisting of "price type", a code set, "currency
> code", another code set, and "quantity", a data format.

On the Simple form you can use Amount, which combines decimal and currency code. Price type is another code set, defined in another attribute of the price complex element. For the time being this should be another simple data type defined as a code list. (The registry will not specify whether or not this should be used as a qualifying attribute or an embedded component of a price, which is up to the DTD writer. It simply captures this as another piece of information that needs to be recorded.) Quantity is also a separate data field, defined using the predefined Quantity datatype (for which I have no idea of the what form it take I'm afraid!). So what you end up with is
 
Complex component: DealPrice
    Simple Component: Deal Type (Datatype=Code List)
    Simple Component: Amount (Datatype=Amount)
    Simple Component: Quantity (Datatype=Quantity)

Seems to provide what you are requesting without problems.

> My conclusion is that the methodology documented in Hisano's paper and
> embodied in Martin's forms, and the methodology we were following in San
> Jose with the spreadsheets and standardized representation classes, are
> significantly different methodologies. For example, both use the term
> "representation class" but refer to entirely different concept by that name.

Depends which of my forms you are talking about. The forms defined before San Jose do not correspond with Hisanao's paper as they presume that datatyping requirements are more complex than the simple "representation classes" proposed in the original paper. That is why the forms are referred to as Data Format and Code Set, and do not use the term representation class. The new "simplified" form has a simpler Data Representation Type field that maps directly to Hisanaios "representation classes" but which does not formally define any of these terms, or allow you to define your own "variants" on them, which is what you (quite rightly in my view)  seem to need to do.

> I wanted to try to be more rigorous about this analysis but that would have
> required my finding a copy of the list of representation classes before the
> summer ended, the budget nightmare started, and the intern who was doing
> this for me went back to school.

Someone needs to do the rigorous analysis - at some time we need formal definitions, in terms processable by XML Schemas, of all representation classes listed in the Simple form. We also need a mechanism for the likes of Dwight to define new representation classes.

Hope this helps.

Martin

---