RE: OTA Tag name rules

["Sohaib.J.Kidwai" <sohaibk@ecomxml.com>]

> But before you say 'Yech' (as I believe one of your colleagues commented
so
> vividly), consider this:  OTA has become the acknowledged leader in moving
> the travel industry to XML.  See the recent article in Computerworld,
> http://www.computerworld.com/cwi/story/0,1199,NAV65-665_STO51231,00.html
as
> evidence.  I only hope other industries accept ebXML to this extent.

Here is yet another colleague with a "yech". 90% of the world's computers
use Windows. This fact according to Microsoft makes it the leader in moving
ignorant users like myself to computers ? Does'nt stop me from still saying
yech when I see BSDs.

> The issues raised on the list were the very issues we discussed last year
> at this time, all of which are still valid.

One year in our craft is a reasonably long time. The point of the argument
was simply to revisit the issue or least of all to explain to newer visitors
to this forum of the reason for the selection of such tag names.

> I only hope other industries accept ebXML to this extent.

Cannot agree more. Might I also add that to ensure acceptance, a small
effort may be required to cooperate with newer visitors (with interests in
ebXML implementations) rather than push them around into different forums.

Regards,
Sohaib.J.Kidwai
Senior Java Architect
Phone: (215)-321-5569
Reply To: sohaibk@ecomxml.com
EComXML, Inc.
http://www.ecomxml.com


-----Original Message-----
From: Alan Kotok [mailto:akotok@disa.org]
Sent: Friday, September 29, 2000 3:01 PM
To: Sam Hunting; Christopher Ferris
Cc: Scott Hinkelman/Austin/IBM; ebxml-architecture@lists.ebxml.org
Subject: Re: OTA Tag name rules


Sam, et al.

I am on the Architecture list for observer purposes, but with the
continuing discussion of the OTA tag naming conventions, I thought I would
chime in.  During the development of OTA's version 1, I served as OTA's
standards manager, so perhaps I can shed some light on the questions
raised.  Scott Hinkelman may have touched on some of these issues in a
previous message; if I repeat what he says, my apologies.

We put the version number in the tags to handle the scenario of OTA
messages containing components from multiple versions of the
specification.  In this situation, we could not guarantee backward
compatibility with previous versions and thus, to play it safe, decided on
including version number as part of the tag.

We built the hierarchy into the tags in order to avoid duplicate-naming
collisions and to help prepare for an eventual migration to
XML-Schema.  Again, we erred on the side of caution, not knowing to what
extent the specifications would expand in the future.

The issues raised on the list were the very issues we discussed last year
at this time, all of which are still valid.  With little in the way of
guidance, and with very short deadlines (four months from a dead start to
draft specification) we took our best shots.    We received a few comments
in the internal and public reviews about the resulting size of the tags,
but no one thought they were particularly difficult to implement.  Also, we
received no suggestions of other ways to meet these requirements.

That was then, and this is now.  Are there better ways to skin these
cats?  Probably so, which is one reason why OTA so strongly supports the
work of ebXML.  With a year's worth of deliberations of probably the best
minds in the business, you will likely do a better job of defining
solutions than we did at OTA.  And OTA is committed to aligning its
specifications with ebXML.

But before you say 'Yech' (as I believe one of your colleagues commented so
vividly), consider this:  OTA has become the acknowledged leader in moving
the travel industry to XML.  See the recent article in Computerworld,
http://www.computerworld.com/cwi/story/0,1199,NAV65-665_STO51231,00.html as
evidence.  I only hope other industries accept ebXML to this extent.

Thanks for your indulgence; I will return to lurk mode.

Alan Kotok
Director, Education and Information Resources
Data Interchange Standards Association
akotok@disa.org
+1 703-518-4174
** DISA's E-Business and Internet Conference, 7-9 March 2001, in San
Francisco.
http://www.disa.org/conference/annual_conf/index.htm **



At 01:56 PM 9/29/00 -0700, Sam Hunting wrote:
>Response inline below as parent of  <sh>.
>
>
> >
> >
> > Sam Hunting wrote:
> > >
> > > > Prefixes will use a period (.) as a separator.
> > >
> > > Are there advocates for this practice on ebXML?
> > >
> > > > Example: <v1.Cust.Pay.CreditCard>
> >
> > Yech! Putting the version in the tag name seems to me to
> > be a colossal mistake. I could see adding a version attribute
> > to each element (possibly) but having different tag names
> > would necessarily require code modifications if in nothing
> > other than XSLT stylesheets. Not a good idea, IMHO. I certainly
> > would hope that ebXML would NOT adopt this practice or standard!
>
><agreement kind="violent">
>
><sh>I would think that it should be an architectural  requirement that
ebXML
>minimize "churn"
>when new revisions of the standard come out.
>
>You allude to code modification, but there is also the issue of document
>modification --
>
>Surely we do not want to require users to have to convert all of their
>documents (could be terabytes!) from  <v1.foo> to <v2.foo> when a new
>version of the standard comes out!
>
></sh>
>
></agreeement>
>
> > > > OTA's tag naming conventions include the specification version and
>content
> > > > hierarchy as prefixes and, as a result, will require greater
bandwidth
>to
> > > transmit than tags with
> > > > more cryptic codes. OTA made the decision to include this much text
in
>the
> > > tags
> > > > so OTA could convert the data model to XML-Schema as
> > > > easily as possible. XML-Schema will not need the context or
hierarchy
> > > included in the tag
> > > > names, which will reduce their size.
> > >
> > > Is there anyone on the list privy to these discussions?
> > >
> > >     (1)  What is the "context or hierarchy" involved that can't be
>expressed
> > > by more typical nested containment?
> >
> > Good question!
> >
> > >
> > >     (2) Why can't the "context or hierarchy" be expressed in DTDs as
>opposed
> > > to schemas?
> >
> > Good question
> >
> > >
> > >     (3) Why put the "context or hierarchy" in the element names?
> >
> > Yes, indeed! What ever for!
> >
> > >
> > > Thanks in advance.
> >
> > --
> >     _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
> >    _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
> >   _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
> >        _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
> > _/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903
> >