OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [ubl-lcsc] FW: [ubl-ndrsc] Joint NDR/LC calls Tuesday and Wednesday

For our discussion this AM...

-----Original Message-----
From: Burcham, Bill 
Sent: Tuesday, January 21, 2003 8:42 AM
To: 'jon.bosak@sun.com'; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Joint NDR/LC calls Tuesday and Wednesday

On the "long tag names" issue I'd like to provide for our discussion this
AM, a chronology I just developed.  I believe that the schema/scripts as
they existed last Thursday are closest to what is needed.  Also, I have
generated HTML documentation of Thursday's schema.  It's 700K zipped so I
won't attach it.  Please message me if you'd like a copy for our discussion.
It makes the type and element reuse apparent -- for instance you can look at
the doc for the "AdditionalStreet" element and see that it's "used by" all
of: AddressDetailsType DeliverToAddressDetailsType
JurisdictionAddressDetailsType RegistrationAddressDetailsType
SendFromAddressDetailsType. (all that reuse went away on Friday).

Here's the chronology:

Wednesday, January 15, 2003 (UBL_Reusable_05.xsd)

Global element declaration for "ID" carries annotation from
TransportEquipmentSeal (this is incorrect -- there should be no
documentation on the global element declaration since there is no
corresponding documentation in the source model -- yet).

<xsd:element name="ID" type="cct:IdentifierType" id="UBL000656">
<xsd:annotation> <xsd:documentation> <ccts:BBIE
dictionaryEntryName="Transport Equipment Seal. Identifier"
definition="identification on a seal on a piece of transport equipment. "
objectClassTerm="Transport Equipment Seal" propertyTerm="Identification"
representationTerm="Identifier"/> </xsd:documentation> </xsd:annotation>

The "ref" to this element from TransportEquipmentSeal has a matching (xml)
id (incorrect -- the referring element represents a Basic BIE Property
whereas the target of the reference represents a Basic BIE (not a Property)
-- they are representing two different modeling elements)

The other "refs" to this element have different (xml) id's (correct).

Thursday, January 16, 2003 (UBL_Reusable_05_tim_draft.xsd)

Global element declaration for "ID" no longer carries an annotation
(correct!).  Further, the (xml) id attribute is gone from that element
declaration.  That's probably also correct since we don't model the reused
BBIEPs yet (in the spreadsheets).  

For some reason AccountsContact.Identifier defines it's own (without a ref)
id element.  incorrect  This appears to be an abberation -- perhaps the Tim
was experimenting?

All the "refs" to the ID element have different (xml) id values (correct!)

Friday, January 17, 2003 (UBL_Library_0p70_Reusable.xsd)

Long tag names introduced and all sharing of element declarations is
eliminated.  For every (globally declared) element there is exactly one

<xsd:element name="TransportEquipmentMeasurementTransportEquipment"
type="TransportEquipmentDetailsType" id="UBL000654"/> These elements carry
the annotation from the BBIEP.

-----Original Message-----
From: Jon Bosak [mailto:Jon.Bosak@sun.com] 
Sent: Monday, January 20, 2003 10:01 PM
To: ubl-ndrsc@lists.oasis-open.org
Subject: [ubl-ndrsc] Joint NDR/LC calls Tuesday and Wednesday

As you all know, some concerns have arisen regarding the current form of the
UBL 0p70 schemas.  Since my primary role in this effort is organization and
marketing, I generally don't try to manage the technical side, and until
today my 50,000-foot impression was that the current discussion was
primarily about the verbosity of fully qualified names, an issue that in
itself does not overly concern me.  I now realize something that should have
caught my attention earlier, which is that the current names are not just
really long but are now also structured in a way that prevents code reuse.
This should have been obvious, and would have been obvious if I had caught
Bill Burcham's messages to the NDR list last week, but the importance of the
problem has become clear to me only through findings posted by Ken Holman to
the LC list Sunday as a result of his attempt to make stylesheets conforming
to the schemas:


Based on these messages, and also on Ken's comments in Monday's LC SC call,
it appears that the current naming method will create serious problems for
implementers -- problems of a different order than just assigning enough
memory space.

I am always ready to tell implementers that later changes to a specification
in progress may require them to rewrite their prototypes, but I hesitate to
put out for review something that may make it too hard to create prototypes
in the first place.  So before we go public with the schemas in their
present form, I'd like us to revisit this issue together.

For this purpose, I'm asking that a portion of tomorrow's regularly
scheduled LC meeting (8-10 a.m. California time Tuesday 21 January
2003) and the next day's regularly scheduled NDR meeting (8:30-10:30 a.m.
California time Wednesday 22 January) be joint LC/NDR meetings devoted to
this topic.  I've listed the times and dial-in numbers below.

Under ordinary circumstances, this would be Tim McGrath's decision, but he's
been called away on personal business and can't be reached right now.  I
hope very much that he will be back in range for these joint conference
calls.  Marion Royal is chairing LC SC in Tim's absence, but I came to this
understanding too late to call him Monday night; I hope he will forgive my
adding this issue to his Tuesday morning LC review agenda.

The biggest unresolved question appears to be whether it's actually
necessary to have multiple uniquely named elements for things that are bound
to the same type:


I think that we need to be absolutely sure of the necessity for this before
we give up on easy code reuse.  If it's not necessary, then we need to
estimate what would be required to fix this without seriously putting the
release further behind.

Another technical question that needs to be resolved is the use of


Dial-in info:

   LC SC call Tuesday 21 January 2003 8-10 a.m. PST
   U.S. Dial In Number: 877 494 5165
   Int'l Access/Caller Paid Dial In Number: 405 319 0674

   NDR SC call Wednesday 22 January 2003 8:30-10:30 a.m. PST
   U.S. Dial In Number: 888 422 7116
   Int'l Access/Caller Paid Dial In Number: 608 250 1828


To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC