RE: [ubl-ndrsc] Minutes February 12 2003

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

Some comments on Eve's comments (single >) to Mavis minutes (double >>) and on Mavis minutes

Mavis wrote - 
> > Action items:
> > It would be very useful if we could talk to UN/ECE about the adoption our
> > rules in the republication of their code lists.
> > Mark will see if a resource is available to be the front lead on this to
> > UN/ECE

What I said was that I will see if I have a resource to do the technical front piece.  I need some clarification from the list on exactly what is required here, but believe that I can have one of my developers do what is needed to support this work.

Mavis wrote - 
> > Arofan and Lisa will update Eve's sample country code and 
>> currency code lists and provide technical assistance required for the testing.

Not sure how this is different from the preceding.  Please clarify as I assumed one of the things that needed to be done was to either have UN/ECE provide a code list or I needed to create it.


Eve wrote -  
> I think what would be most productive is to start with the 
> UN/ECE code list schema modules and try to work with them to get them into 
> compliance (but notice that we need to modify our own rules 
> to get them, in turn, into CCTS 1.90 compliance first!).  But if the UN/ECE folks 
> aren't interested or don't have time right now, then I think it's fair 
> to mock up "country code" and "currency code" modules based 
> on theirs, but eliding or perhaps faking most of the real content.

I agree, however it would be beneficial if Eve could identify which of our rules she believes are not in compliance with CCTS 1.9.
.

Mavis wrote -  
> > There was a discussion on enumeration as per our code list proposal. This
> > works largely for fairly static code lists. David Webber rightly points out
> > that for very dynamic code lists like HL7 XML schema is not very useful as is
> > the case with static ones.
> > Jessica's group have also difficulties accepting the enumerated list part of
> > our proposal.
> > Arofan suggested that we should bring Tony Coates from TC154 who wrote Best
> > Practice on Enumeration more in to our loop.

And Eve wrote -  
> To be clear, our rules do not mandate or even recommend enumeration. 
> The amount and type of constraints put on the code values is 
> entirely up to the code list producer.

I am not sure I completely understand or agree with this.  I thought our whole purpose was to get us out of the business of duplicating code lists through enumeration while maintaining the ability to do server validation of the codes.  Eve's solution was a way that other standards bodies would publish their code lists in an accessible fashion, we would import them on demand rather than enumerate them ourselves, and thus preserve runtime server validation without having to maintain duplicates of the code lists.  As such, we absolutely need enumerated lists, and it is inconsequential to us if the list is dynamic or static. In fact, a dynamic list seems even better suited to this than a static one.  I fail to see how pattern matching offers any value in addressing this problem, as we can simply define the pattern ourselves from a quick analysis of existing code lists. 


Eve wrote -  

> Well, "reject" is pretty strong... :-)  What I suspect Gunther was 
> worried about was huge numbers of namespace declarations in 
> the instance (e.g., if there are codes of 70 different types in a single instance). 
> But because we decided a long time ago to bind foreign code types to 
> native UBL elements, I don't think the instance ever has to know about 
> the foreign namespaces underlying the types bound to the elements.  Now, 
> the *schema* will have to have a ton of namespaces declared, so maybe 
> that's what Gunther was concerned about.

Has anyone done any analysis on the relationship between numbers of namespace declarations and server performance?



Mavis wrote - 
> > - Code lists, A Priority. Lisa will update the document 
> pending outcome ofthe beta test. Lisa and Arofan will fix up Eve's two code 
> list samples.

I thought this was -

	Mark to identify resource to do front end technical work, to include fixing up Eve's two samples and conducting test.  Code list paper on hold until examples are fixed and testing complete. 


Mavis Wrote - 

> > 7. Embedded documentation (Gunther/Mavis)
> > 
> > Jon:  We decided that not everything that is in the current 
> spreadsheet
> > deserves to be in the schema documentation. The 
> responsibility for deciding
> > this is left to LCSC and the spreadsheet designers.
> > Arofan: The contents of the spreadsheet alone would not suffice as
> > documentation for implementation.
> > Mavis: NDRs decision is on the format. Two proposals 
> currently one on XHTML
> > and one on Docbook. Docbook is proposed by Gunther for the extra
> > non-spreadsheet information.

I don't want to loose the point I made that there has to be some level of restriction on what LCSC may want to put into the schema.  I still contend that we should limit our documentation to what is called for in section 7 of the CCTS.  We also need to remind the LCSC that they need to validate the contents of the spreadsheet against the CCTS storage requirements.
 
Mark