[ubl-lcsc] Re: [ubl-ndrsc] MINUTES: Joint NDR/LCCSC 4 Feb 2003

[Tim McGrath <tmcgrath@portcomm.com.au>]

i am afraid i missed this call, so i greatly appreciate the minutes being
so rapidly prepared and distributed.

please note my comments inline.

I shall endeavour to call in on the Wednesday p.m. call, if this will be
a time to discuss these.

Lisa-Aeon wrote:

The following are the minutes from today's joint meeting.  Please, Arofan, Bill, Eve, and others, read through them carefully, either comment by email or joint the call tomorrow afternoon.  We appreciate having your input.

 

Roll call:
Jon Bosak
Dave Carlson
Mavis Cournane
Mark Crawford
Fabrice Desre
Lisa Seaburg
Eduardo Gutentag
Bill Meadows
Mike Adcock
Gareth Minikawa
Paul Thorpe
Kevin ?
Dan Vint
Alan Stitzer
Jim Wilson
Sue Probert
Marion Royal
Gunther Stuhec
Stig Korsgaard

 

Discussion Topic 1: Context Methodology
Marion asks about a copy of Ken's message about Draft Guidelines for UBL Instance Creation. He suggests they have some specific questions that they would like some help on. Eduardo says it was Ken's way of figuring out how to do something without being informed about the Context Methodology. The paper is about extension. Ken summarizes other people's approaches to doing extensions, one of them is Sally's approach to extensions, Tim's thoughts as well as his own.

 

as is implied this was not based on the CM thinking - just some prototyping.
 I don't think we need to get too involved with the results - mine was a
throw away and based on ignorance about the working of XSD - it isn't my
thinking on how extension should be done and i don't want this to be seen
that way.

Eduardo suggests we give Ken our Context Methodology and attend a concall about it.
Jon wants to make sure we don't lose what they have been going through with Sally's examples and wanting to know if this is in or outside the guidelines we will give for context methodology manual extension. What LCSC want is a final version of this CM paper as applied to the real-life instances.

rather than focus on Sally's example instances we should be looking at her
requirements.  what are the components that aerospace need? how do they relate
to our models? - once we know what these are we can clearly see where and
how the context methodology should be applied.
if we focus on the end product (a propose instance) and work back we are
mssing the big picture on this.

 

Eduardo proposes to be given time until Thurs evening to do another pass on the Guidelines and then send it to library for reading and see if it is satisfactory by Fri. He will look at Ken's paper and possibly Sally's examples. These are presented as instances not schemas which makes things a little more difficult.

 

i agree, we need to be modeling not working with instacnes.  this is my point
above - the models we have are spreaadsheets, class diagrams and schemas.
 these are the forms we should be discussing.

Sally is using a purchase order instance without applying our purchase order schema.  She is working under the assumption that she is UBL compliant, but I think there are questions about this.  She is using a schema generated off of her own spreadsheets, it is the same UBL Perl script we use.  This gives her a false impression that she is UBL compliant.  This needs to be addressed fully.

 

i agree again.  if, by 'compliance' we mean interoperable with other UBL
implementations, then we have to be clear that the perl-script gives us NDR
(syntax) only.  it is the content models that give us interoperability -
i.e. using the components of UBL and applying the context methodology to
them.

Discussion Topic 2: Review XML instances
There are no sample instances right now that use the UBL schema. It would be more efficient to send out the revised CM paper.
Since this release there has been a turning point between the relationship between spreadsheet and schemas. We now have to maintain both the schema and the spreadsheet and they both have to be dealt with both of them at once. Hopefully, this can be done by changing the tool that is between them. We want Sally to roadtest the CM document (first we have to address the schema output and what schema she is using.  If its not UBL schema, then its irrelevant.

 

maybe i am missing soemthing here but there are (at least) three sample instances
of Order using the current UBL 0p70 schemas.  Ken has two he updated from
the previous release and I created one from Sally's data.  please find these
attached.

Mike will make some documents available to NDR i.e. Message Assembly Primer 1 and 2.

 

Discussion Topic 3: UBL documentation
Does LCSC envisage a UBL primer. They have a primer for document assembly.

 

NDR has two types of documentation. The first one is all of the information that we find in the spreadsheet. This would be included in the schema under a single documentation element as individual attributes. Level 2 is more detailed syntax specific implementation details, the usage of BIEs, links to UML diagrams. This would be for example for every type declaration we would give an XML instance example. In the schema we need the documentation of what we consider to be the normative description.

 

A documentation change would mean a version of the schema change. Our legal room is what we want to consider normative. A level of detail might not trigger a version update of the schema.

 

The release has all of the information within the spreadsheets, debate is: do we need more, and how much more.  This goes back to this mornings discussion, how much information.  One of our options is to include a lot more than in available in the spreadsheet now.  This would mean all information about the structures would live within the schema.  This is not a majority view.  This is the extreme case of what we had been discussing.  Some of this documentation could be references to outside documentation.

 

SAP as a generic user of UBL would like the extreme case.

 

If we put it all into the schema and we say this is normative, we run into the same problem as always: if you make mistakes, you have to live with them.  Would this text be normative?

 

Jons: Maybe we have a runtime version and an annotated schema, which would include this information.  The annotated schema would not be normative.  There is a limit to how much you can make normative.

 

Questions:
   How to maintain the documentation in the schema? 
   How much documentation belongs in the schema, what are the choices here?
   How much of the text needs to be normative?

 

At this point the meeting was brought to a halt as we tried to get the teleconference going.  The LCSC decided to try their call from the rooms.

 

Jon's proposal:  We can not publish schema without comments, we don't want to publish a huge schema with everything as our schema.  My suggestion is, what is in the spreadsheet is what goes into the schema. 

 

 

my take on this is that the XML schemas are themselves metadata, they describe
the model of our data.  As such they are logically equivalent to the spreadsheets
and the UML diagrams.  it is just that the XML schemas are more machine processable
representations.
Remember we only use spreadsheets because of ease of maintenance, but the 
trade off has been the perl-script coversion.  this debate has been spurned 
by that strategy.  I dont' have a problem with the extreme view - where a
schema describes the entire conceptual model.  One day we want to remove
the need for spreadsheets and XML schemas are the obvious way to go.  
maybe what we are looking at is a single schema that describes the entire
normalized model and then  a context methodology that asemebles specific
document schemas (based ont heir conetxt drivers).

ps personally, i am not sure any annotation needs to be normative - the documentation
does not immediately impact interoperability.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.441 / Virus Database: 247 - Release Date: 1/9/2003

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142

Attachment: boeing-example-tim.xml
Description: text/xml

Attachment: 220order1.xml
Description: text/xml

Attachment: 220order2.xml
Description: text/xml