[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-ndrsc] MINUTES: Joint NDR/LCCSC 4 Feb 2003
Tim McGrath wrote: > 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. Good, we're in agreement > >> 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. Right, we agree. > >> >> 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. RIght. > >> 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. Right. Hm, we seem to be in violent agreement, why do we even have to talk about this? ;-) > >> 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. So let's see if we're in sync: there are three instances of Order, created based on the UBL Order schema, and the three of them validate against that Schema? So if you created an Order from Sally's data, what happened to the data she had that required customization? > >> 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. I beg to disagree. If the documentation says that a developer should treat a given element or attribute in a certain way, but the documentation is not normative, then different developers will treat that element or attribute differently, and you've just killed interoperability. Even taking your point above, that schemas are equivalent to the spreadsheets and the UML diagrams, then we should treat the documentation comments in the spreadsheet that need to be normative exactly the same in the schema, shouldn't we? > >> >> --- >> 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 > > > > ------------------------------------------------------------------------ > > <?xml version="1.0" encoding="UTF-8"?> > <po:Order xmlns:po="urn:oasis:names:tc:ubl:Order:1.0:0.70" xmlns:cat="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70" xmlns:cct="urn:oasis:names:tc:ubl:CoreComponentTypes:1.0:0.70" xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1.0:0.70" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="urn:oasis:names:tc:ubl:Order:1.0:0.70 > UBL_Library_0p70_Order.xsd"> > <cat:ID>AWACS0001</cat:ID> > <cat:IssueDate>2003-01-01</cat:IssueDate> > <!-- added mandatory element --> > <cat:BuyerParty> > <cat:ID>JA1</cat:ID> > </cat:BuyerParty> > <cat:SellerParty> > <cat:ID>81205</cat:ID> > </cat:SellerParty> > <cat:SalesConditions> > <!-- ccsd:OrderResponseProcessing.Priority.Code --> > <cat:ConditionID/> > <cat:ActionCode>AOG</cat:ActionCode> > </cat:SalesConditions> > <cat:DeliveryTerms> > <ID>1</ID> > <cat:SpecialTerms>HOLD FOR PICKUP. NOTIFY JOHN DOE 253-773-1234 WHEN SHIPPED. > </cat:SpecialTerms> > </cat:DeliveryTerms> > <cat:OrderLine> > <cat:BuyersID/> > <cat:Quantity unitCode="EA">5</cat:Quantity> > <cat:Item> > <cat:ID/> > <cat:ManufacturersItemIdentification> > <cat:ID schemeAgencyID="81205">256T2800122</cat:ID> > <!-- using the schemaAgencyID for the Manufacturer's ID --> > </cat:ManufacturersItemIdentification> > <cat:CatalogueItemIdentification> > <!-- using catalog to define industry identification codes --> > <cat:ID>N000001</cat:ID> > </cat:CatalogueItemIdentification> > <cat:ReferencedCatalogue> > <cat:CatalogueID>AviationAuthority</cat:CatalogueID> > </cat:ReferencedCatalogue> > <cat:BasePrice> > <cat:PriceAmount currencyID="USD">100</cat:PriceAmount> > </cat:BasePrice> > </cat:Item> > <cat:DeliveryRequirement> > <cat:ID/> > <cat:DeliverToAddress> > <cat:ID>01</cat:ID> > </cat:DeliverToAddress> > </cat:DeliveryRequirement> > <cat:OrderedShipment> > <cat:ID/> > <cat:ShipmentStage> > <cat:StageID/> > <cat:TransitPeriod> > <cat:StartDateTimeDate>2002-07-01</cat:StartDateTimeDate> > <!-- This is for complex because it is the required shipping date - not the required delivery date --> > </cat:TransitPeriod> > </cat:ShipmentStage> > </cat:OrderedShipment> > </cat:OrderLine> > <cat:Contract> > <cat:ID>JAPAN-AWACS-TEST</cat:ID> > </cat:Contract> > </po:Order> > > > ------------------------------------------------------------------------ > > <?xml version="1.0" encoding="UTF-8"?> > <po:Order xmlns:po="urn:oasis:names:tc:ubl:Order:1.0:0.70" xmlns="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70" xmlns:cct="urn:oasis:names:tc:ubl:CoreComponentTypes:1.0:0.70" xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1.0:0.70" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="urn:oasis:names:tc:ubl:Order:1.0:0.70 > UBL_Library_0p70_Order.xsd"> > <ID>4500004875</ID> > <IssueDate>2001-12-17</IssueDate> > <po:TransactionCurrencyCode>USD</po:TransactionCurrencyCode> > <GrossWeightMeasure unitCode="kg">50</GrossWeightMeasure> > <GrossVolumeMeasure unitCode="m3">7</GrossVolumeMeasure> > <BuyerParty> > <ID>R300</ID> > <PartyName> > <Name>IDES Retail INC US</Name> > </PartyName> > <Address> > <ID/> > <Street>West Chester Pike</Street> > <CityName>Parsippany</CityName> > <CountrySub-EntityCode listID="3166-2" listAgencyID="ISO">NY</CountrySub-EntityCode> > <Country> > <Code listID="3166-1" listAgencyID="ISO">US</Code> > </Country> > </Address> > <BuyerContact> > <ID/> > <Name>Joe Bloggs</Name> > </BuyerContact> > </BuyerParty> > <SellerParty> > <ID>R3002</ID> > <PartyName> > <Name>Meyer Hardware Inc.</Name> > </PartyName> > <Address> > <ID/> > <Street>South Hollow Road</Street> > <CityName>London</CityName> > <Country> > <Code listID="3166-1" listAgencyID="ISO">UK</Code> > </Country> > </Address> > </SellerParty> > <DestinationCountry> > <Code listID="3166-1" listAgencyID="ISO">US</Code> > </DestinationCountry> > <OrderLine> > <BuyersID/> > <Quantity unitCode="unit">10</Quantity> > <Item> > <ID>R100016</ID> > <Description>Tuner X300</Description> > <BasePrice> > <PriceAmount currencyID="USD">350</PriceAmount> > </BasePrice> > </Item> > <DeliveryRequirement> > <ID/> > </DeliveryRequirement> > </OrderLine> > </po:Order> > > > ------------------------------------------------------------------------ > > <?xml version="1.0" encoding="UTF-8"?> > <po:Order xmlns:po="urn:oasis:names:tc:ubl:Order:1.0:0.70" xmlns="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70" xmlns:cct="urn:oasis:names:tc:ubl:CoreComponentTypes:1.0:0.70" xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1.0:0.70" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="urn:oasis:names:tc:ubl:Order:1.0:0.70 > UBL_Library_0p70_Order.xsd"> > <ID>4500004875</ID> > <IssueDate>2001-12-17</IssueDate> > <po:TransactionCurrencyCode>USD</po:TransactionCurrencyCode> > <GrossWeightMeasure unitCode="kg">50</GrossWeightMeasure> > <GrossVolumeMeasure unitCode="m3">7</GrossVolumeMeasure> > <BuyerParty> > <ID>R300</ID> > <PartyName> > <Name>IDES Retail INC US</Name> > </PartyName> > <Address> > <ID/> > <Street>West Chester Pike</Street> > <CityName>Parsippany</CityName> > <CountrySub-EntityCode listID="3166-2" listAgencyID="ISO">NY</CountrySub-EntityCode> > <Country> > <Code listID="3166-1" listAgencyID="ISO">US</Code> > </Country> > </Address> > <BuyerContact> > <ID/> > <Name>Joe Bloggs</Name> > </BuyerContact> > </BuyerParty> > <SellerParty> > <ID>R3002</ID> > <PartyName> > <Name>Meyer Hardware Inc.</Name> > </PartyName> > <Address> > <ID/> > <Street>South Hollow Road</Street> > <CityName>London</CityName> > <Country> > <Code listID="3166-1" listAgencyID="ISO">UK</Code> > </Country> > </Address> > </SellerParty> > <DestinationCountry> > <Code listID="3166-1" listAgencyID="ISO">US</Code> > </DestinationCountry> > <OrderLine> > <BuyersID/> > <Quantity unitCode="unit">10</Quantity> > <Item> > <ID>R100016</ID> > <Description>Tuner X300A</Description> > <BasePrice> > <PriceAmount currencyID="USD">350</PriceAmount> > </BasePrice> > </Item> > <DeliveryRequirement> > <ID/> > </DeliveryRequirement> > </OrderLine> > <OrderLine> > <BuyersID/> > <Quantity unitCode="unit">6</Quantity> > <Item> > <ID>R100016</ID> > <Description>Tuner X300C</Description> > <BasePrice> > <PriceAmount currencyID="USD">250</PriceAmount> > </BasePrice> > </Item> > <DeliveryRequirement> > <ID/> > </DeliveryRequirement> > </OrderLine> > <OrderLine> > <BuyersID/> > <Quantity unitCode="unit">2</Quantity> > <Item> > <ID>R100016</ID> > <Description>Tuner X300E</Description> > <BasePrice> > <PriceAmount currencyID="USD">420</PriceAmount> > </BasePrice> > </Item> > <DeliveryRequirement> > <ID/> > </DeliveryRequirement> > </OrderLine> > <OrderLine> > <BuyersID/> > <Quantity unitCode="unit">7</Quantity> > <Item> > <ID>R100016</ID> > <Description>Tuner X300G</Description> > <BasePrice> > <PriceAmount currencyID="USD">1350</PriceAmount> > </BasePrice> > </Item> > <DeliveryRequirement> > <ID/> > </DeliveryRequirement> > </OrderLine> > <OrderLine> > <BuyersID/> > <Quantity unitCode="unit">7</Quantity> > <Item> > <ID>R100016</ID> > <Description>Tuner X300I</Description> > <BasePrice> > <PriceAmount currencyID="USD">175.37</PriceAmount> > </BasePrice> > </Item> > <DeliveryRequirement> > <ID/> > </DeliveryRequirement> > </OrderLine> > <OrderLine> > <BuyersID/> > <Quantity unitCode="unit">3</Quantity> > <Item> > <ID>R100016</ID> > <Description>Tuner X300K</Description> > <BasePrice> > <PriceAmount currencyID="USD">350</PriceAmount> > </BasePrice> > </Item> > <DeliveryRequirement> > <ID/> > </DeliveryRequirement> > </OrderLine> > <OrderLine> > <BuyersID/> > <Quantity unitCode="unit">1</Quantity> > <Item> > <ID>R100016</ID> > <Description>Tuner X300M</Description> > <BasePrice> > <PriceAmount currencyID="USD">325</PriceAmount> > </BasePrice> > </Item> > <DeliveryRequirement> > <ID/> > </DeliveryRequirement> > </OrderLine> > <OrderLine> > <BuyersID/> > <Quantity unitCode="unit">2</Quantity> > <Item> > <ID>R100016</ID> > <Description>Tuner X300P</Description> > <BasePrice> > <PriceAmount currencyID="USD">350</PriceAmount> > </BasePrice> > </Item> > <DeliveryRequirement> > <ID/> > </DeliveryRequirement> > </OrderLine> > <OrderLine> > <BuyersID/> > <Quantity unitCode="unit">4</Quantity> > <Item> > <ID>R100016</ID> > <Description>Tuner X300Q</Description> > <BasePrice> > <PriceAmount currencyID="USD">550</PriceAmount> > </BasePrice> > </Item> > <DeliveryRequirement> > <ID/> > </DeliveryRequirement> > </OrderLine> > <OrderLine> > <BuyersID/> > <Quantity unitCode="unit">11</Quantity> > <Item> > <ID>R100016</ID> > <Description>Tuner X300S</Description> > <BasePrice> > <PriceAmount currencyID="USD">350</PriceAmount> > </BasePrice> > </Item> > <DeliveryRequirement> > <ID/> > </DeliveryRequirement> > </OrderLine> > </po:Order> -- Eduardo Gutentag | e-mail: eduardo.gutentag@Sun.COM Web Technologies and Standards | Phone: +1 510 550 4616 x31442 Sun Microsystems Inc. | 1800 Harrison St. Oakland, CA 94612 W3C AC Rep / OASIS TAB Chair
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC