Re: OTA Tag name rules

[Sam Hunting <shunting@ecomxml.com>]

See, eg, http://www.rpbourret.com/xml/NamespacesFAQ.htm#p1

----- Original Message -----
From: "Scott Hinkelman/Austin/IBM" <srh@us.ibm.com>
To: "Sam Hunting" <shunting@ecomxml.com>
Cc: <ebxml-architecture@lists.ebxml.org>
Sent: Thursday, September 28, 2000 12:56 PM
Subject: Re: OTA Tag name rules


> This happened a year ago (Namespaces where not the norm,
> imature, or not desired) so the details of discussion are not fresh.
> The issues center around the fact that the DTD name space is flat.
> OTA needs to have
> the CarRental group progress through time with increasing releases
> at a different pace than the Airline group. Prefixing the tag names
> to provide context and avoid collision is one approach to this problem.
> As the technology advances, some of this is being reconsidered for the
next
> rev.
>
> I am not suggesting adopting these conventions, but these are some of the
> issues.
>
> Thanks,
> Scott Hinkelman, Senior Software Engineer
> XML Industry Enablement
> IBM e-business Standards Strategy
> 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> srh@us.ibm.com, Fax: 512-838-1074
>
>
>
> Sam Hunting <shunting@ecomxml.com> on 09/28/2000 02:57:39 PM
>
> To:   Scott Hinkelman/Austin/IBM@IBMUS, ebxml-architecture@lists.ebxml.org
> cc:
> Subject:  Re: OTA Tag name rules
>
>
>
> > Prefixes will use a period (.) as a separator.
>
> Are there advocates for this practice on ebXML?
>
> > Example: <v1.Cust.Pay.CreditCard>
> > 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?
>
>     (2) Why can't the "context or hierarchy" be expressed in DTDs as
> opposed
> to schemas?
>
>     (3) Why put the "context or hierarchy" in the element names?
>
> Thanks in advance.
>
>
>
>
>
>
>
>
>