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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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

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

I'm not anxious to open a can of worms, but since it is apparently at
least partially open anyway, let me briefly outline some of my concerns
on this matter. I found out about the decision to go with global
elements after the fact (which was purely my fault), and I had
reservations about this immediately. There is the risk that we are
introducing a "hack" into UBL that might serve as a bandaid for the
short term, but which should hopefully be made irrelevant over the
longer term as more processors and human users become schema (and, thus,
type) aware.

There aren't only the problems of element reuse that Ken points out.
There is also a problem of perception and subsequent adoption. The
extreme case is tag names like
"ReceivedTransportHandlingUnitHandlingUnitReceiptLine", which would
cause me personally to develop a negative attitude towards UBL off the
bat. I'm not as inflamatory as Eve ;-), so I won't label this a
"freakish nightmare", but it doesn't seem quite right either.

If I understand correctly, the original decision to use global element
names everywhere was intended to enable better reuse of global types
that do not correspond to whole business messages, but might be required
for standalone use. Can someone remind me why we didn't just stick with
the decision to use global elements only for real top-level elements?
This certainly wouldn't preclude having a separate file (and perhaps a
separate namespace) where we could define global elements for all types
to be used as an interim solution until processors are type-aware. The
important point is that these global elements would NOT be used inside
the UBL library.

This might be an inappropriate question to ask at this stage of the
game, but I do feel that problems in the prototyping phase are a clear
sign that design principles should be, at very least, reevaluated and
(presumably) reaffirmed, so I'll play the role of devil's advocate here.


> -----Original Message-----
> From: Jon Bosak [mailto:Jon.Bosak@sun.com]
> Sent: Tuesday, January 21, 2003 5:01 AM
> 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:
>    http://lists.oasis-open.org/archives/ubl-lcsc/200301/msg00085.html
>    http://lists.oasis-open.org/archives/ubl-lcsc/200301/msg00089.html
> 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:
>    http://lists.oasis-open.org/archives/ubl-ndrsc/200301/msg00068.html
> 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
> namespaces:
>    http://lists.oasis-open.org/archives/ubl-ndrsc/200301/msg00072.html
> 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
> Jon
> ----------------------------------------------------------------
> 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