Re: OTA Tag name rules

[Alan Kotok <akotok@disa.org>]

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
> >