CLSC Minutes January 28 2004

[Mavis Cournane <mavis.cournane@cognitran.com>]

Dear all
below are the minutes from last week's call.

Present
Mavis Cournane (chair)
Marty Burns
Sue Probert
Anne Hendry
Paul Spencer
Tony Coates
Michael Dill

Regrets
Ken Holman

TC asks: The question of how to transform the data model was handled in my 
document. The XML description of the code list is important.
MB: I agree with you Tony. It was because of that point, that we put in the 
requirements that the
 data model be expressed in a machine readable form. 
TC: However, we are missing anything about the machine readable form is 
missing, it is too abstract
for me.
MB: We can put in to the section on the data model the machine readable form. 
Do you consider the table
to be representative of the data model you have in mind.

TC: I was thinking we would have a particular standard.
MB: It should be XML, and could be rendered as an XSLT. 
TC: The table you have is what more or less existed in the past 
TC: I need to do the gap analysis.

MB: The idea was to make the data model do the complete set of components.
TC: I will need to add some more text. That will be done by next week.

MB: Could TC embody that table as your data model and write an XSLT that 
displays it that way.Rather than
edit your text edit your data model and generate a visual table from it. We can 
put the XML of the visual model
in an appendix.
TC: The table showed the list of things you would have in the data model and is 
at the same level as the scehma
for the data model and ist at a different lvel to a particular instance. If I 
was to be generating the table as such
I would have to process the schema. I don't know if that particular exercise is 
particularly useful. If I was going
to produce anything that would be a UML model.
AH: I know you were going to have one foot in the tools and one in the codelist 
area, have you had
a chance to talk to Michael Dill about what Edifix requires.
AH: Most of the documents are on the Oasis website.
MD: I am checking whether the current spreadsheet format could really be 
considered as a data model.
In respect of enumerations or code lis Ihave no data so it is difficult to 
play. THere should be a logical link
from data types to enumerations whether they are identifiers or codes.
THis is a conceptual problem of UBL, because datatypes schema is empty and 
there is no equivalent in a non-XML
expression of how they are linked.
TC: I don't think there is enough difference.

MHC: Send the data to Michael, currently we just have spreadsheets and the code 
list catalog and how to link from
the BBIEs to the code lists, we need qualified datatypes + representation term 
qualifiers.
ACTION: TC to provide what we have to Michael.

IF the schema structure and the data is given then it should be easy.
If I start from a data model ie.. from a CCTS based data model, then I have to 
look at a specific way to express it
in a data model and it takes more time.
It is not too difficult to create schemas and it is an issue how to distinguish 
in code list catalog and schema itself.
Qualified datatypes are really needed. 

when the beta data used to create new schemas, and this is when this issue will 
be raised.

TC: Empty code lists should be allowed: 
I am thinking of the model of a code list.
We have to understand we may accept that a code list can be empty but we might 
not have a schema representation for it.
AH: If you go back to using CCTS code type, are you saying that structure would 
have no content but that there would be no structure.
You would have a code list but there would be no entries, but you would have 
all the metadata.
Is it a realistic situation.
TC: Yes, your application code changes between when you might have something 
and then day 65 when you might have smth.
AH: The code list schemas released with Beta are emtpy.
PS: It seems logical to me that this is empty

AGREED: Instruct Marty to modify the paper accordingly.
MHC: All code lists are owned and defined uniquely.
AH: A code list is a BBIE.
MD: I hoped I convinced Tim to change the spreadsheets in terms of the use of 
Datatype and Representation Term.

To plonk an XML representation of a code model is too big a job you could have 
a table. Separately, we should have in the appendix how one should
be represented in XML.

Mark Crawford said the goal was to point to externally maintained code lists, 
but lacking external availability fo these we would produce our own and wrap 
them in our own schemas
and I think the intent would be that they would all be machine readable.

I was hoping that we would produce a machine readable format that was not a 
schema. I was talking at the level of an application of smth that
would wamn to do something with a code list that was not schema validation. 
We would need to produce both the schema and beyond the context of the UBL 
messages. THe aim is to have a more neutral format that lends itself
to being used as a general resource by applications.

MD: The code lists could be expressed in spreadsheets
AH: Steven Green was thinking this could be the lowest common denominator.
TC: The norminative definition of the Code list should be the code list model.

PS: I would suggest the normative version of the code list should be in XML and 
either should be a schema or in XML that could generate a schema.
PS: In the UK eGOV I put forward two syntaxes - one was a schema and one could 
be generated from it. Universally, everyone went for the schema.
I think we should have a normative XML.

TC: The issue is contextual. Validation of UBL document the schema is the 
normative one. 
If on the other hand you are thinking of an applicaiton outside
XML validation it is far less convincing. THat choice is contextualised around 
an XML mindset.

PS: I would suggest the requirement is different. Code lists, when you start 
looking at archival storage 
in 900 years time, a document could still exist
that is using a code list, and that code list still have t be readable. THat is 
the advantage of XML.The code list has an extended life in the way that the 
schemas
for validating a document doesn't.

2. Review of Paul Spencer's Code List requirements
Mandatory requirement - support long term archiving of documents. If you 
archive a document over al ong period, you would archive any code list
that goes with it. The main requirement is to indicate a version, which we do.

The only thing that mitigates this is using fixed values. 
At archival time identify the relevant code list and pull all the references to 
archive them at once.



ACTION:
Paul Spencer to provide these requirements in a list to the CLSC list for 
inclusion in the Requirements document

Regards
Mavis