RE: guidelines on usage of namespaces

[Bob Miller <milr@mindspring.com>]

As one who has stirred the namespace pot, I offer some rebuttals to the comments on this topic.

----------
From:  Duane Nickull [SMTP:duane@xmlglobal.com]
Sent:  Thursday, January 13, 2000 11:35 AM
To:  KETELS Kris
Cc:  ebXML-Architecture@lists.oasis-open.org
Subject:  Re: guidelines on usage of namespaces

Hi Kris:


> Over the last couple of weeks, we've had internally some interesting discussions on the use of namespaces.
> One of the purposes of Namespaces is to avoid data element collision. Now my question is: how granular can one apply a namespace. Is
> it the purpose to have different namespaces at the level of the industry (e.g. Automotive vs financial), at the level of the
> business (e.g. securities vs. payments), technical vs. business (e.g. envelope info vs. payload), at an even lower level (per
> business scenario), or even lower?

I would like to bring everyone up to speed on namespaces becuase some of
our members may not be familiar with the concept.  A namespace, for
those who are not familiar, is a prefix attached to an xml element (the
tag) that basically tells any XML-namespace compliant application
accesing the XML that the element is equal to the element of that name
belonging to the element set defined by the namespace.  In other words, 
the namespace for html applied to XML could look like this:

<html:p>this paragraph should be treated the same as the "p"tag in
html</html:p>

The application's parser must now recognize the html prefix as
specifying that the p tag should be treated the same as the html <p>
(paragraph) element.

The parser knows how to treat the namepsace because you would place a
line in the top of your XML file to point it at your namespace like
this:

<?xml version="1.0"?>
<root_tag xmlns:html="http://www.w3.org/TR/REC-html40">

This tells the parser that anynamespace using the html prefix is to be
conformant to the HTML 4.0 spec.

> What are the consequences of having many namespaces?

The lack of conforming apps and increased processor/parser overhead are
two good reasons for not adopting namespaces right now.  It is
technically a good idea.  I will look at some more issues.

Do you have something like this in mind:

<?xml version="1.0" encoding="UTF-8"?>
<ebxml xmlns:ebxml="http:www.theEbxmlRepository.org/NS/ebxml-objects">
<ebxml:header>
  <ebxml:recipient>you</ebxml:recipient>
  <ebxml:sender>me</ebxml:sender>
</ebxml:header>
<ebxml:message>Hello World</ebxml:message>
</ebxml>

MILR: In the above example, it would make sense to establish the 'ebxml' namespace as the default namespace.

MILR: Actually I would expect that in most cases, none of the element names would have a namespace prefix, as I think users will pick names they like, and in their world there would be no worry about name collisions.  The naming problem I worry about is in the attribute specified in the user's schema/DTD that relates the user's element name
to an entity registered and stored in a repository.  That attribute name itself will be in some XML namespace, and its value may require some qualification of naming authority.  That qualification of a data value is beyond XML Namespace to my knowledge, unless there is some recursion provision I don't know about. 

> Has anyone encountered alike discussions?

Yes - going back two years ago.   There are always arguements ba0out
this going on.  If there isn't,  I know how to instigate one on one of
the main discussion lists (hehehe).

> Should we need to provide some recommendations on when to use namespaces vs. renaming elements (or other methods such use of as
> Xlink and Xpointer) to solve collisions?

This is not within the scope of our group to decide.  The messaging,
transporting group will come up with the solution. If they decide to use
namespaces as a core component of ebXML,  then we will have the task of
implimenting design rules for conformance.
MILR:  But we are responsible for translating business requirements into Technical Architecture specifications.  If there is a business need for multiple naming authorities, then we must support that in our architecture, though we need/should not dictate how it is supported. 

> Should this be discussed in this group or in another (e.g. Core Components, or Repository)?
MILR: Yes to each of the groups mentioned.

See above.


<additional_rants>
There is a strong feeling that ebXML will adopt a set of elements (tags)
to use for common business methods/information objects.  If ebXML adopts
these,  there should be no collision problems.  A repository system
could also be used without collision too.

MILR: In my opinion, it is unreasonable to expect that every semantic element anyone would use will ever be defined by a single naming authority.  It is also unreasonable to expect that XML element names used by an application will be directly usable as a reference to well known semantic elements.  The reference to well known semantic elements will instead be provided through the values of a well known attribute. This association will be made in the Schema/DTD. 

UN/CEFACT and X12 are examples of two naming authorities whose semantic elements have much in common collectively, but each has some semantic elements not in the other domain.  And some 'common' semantic elements have differences in their associated metadata, which may or not be significant.  And of course in the 'real world' these two authoriities encompass but a small subset of all semantic entities one might encounter in electronic commerce.

I strongly support the notion that a 'global' semantic element offers better interoperability than a 'national' ... than a 'partnership' semantic element, in some sort of hierachy of 'betterness'.  Our principles of ebXML usage should reflect that notion.

Another notion I have is that a more/less restrictive semantic element (e.g., an 'industry' semantic element might be a deriative of a more global semantic element.  Consider a 'codelist' that has hundreds of allowable values, whereas in a given industry only a few codes are used.
  

One approach may be to use "ebxml" as a namespace for these tags.  I
would support this becuase we could then define these business
methods/objects within repositories.
Of course, in XML 'ebxml' or 'anyname' can represent the same namespace, since these shorthand names just stand in for the string specified in the xmlns declaration.  
I'd like to see a simple 'synonym' capability in XML, but I don't see that in anyone's XML extension proposals.

</additional_rants>

David Webber has a solution revolving around xlink in the dtd.  His
approach may be more sensible.
MILR:  I've seen some of this stuff.  My first reaction was 'neat, but sounds resource expensive'.  Worth keeping an eye on though.

Duane Nickull
> 
> Best Regards
> Kris
> 
>   ------------------------------------------------------------------------
> 
>   Kris Ketels <kris.ketels@swift.com>
>   Product Manager Standards
>   S.W.I.F.T. sc
>   Standards
> 
>   Kris Ketels
>   Product Manager Standards  <kris.ketels@swift.com>
>   S.W.I.F.T. sc
>   Standards
>                              Fax: +32.2.655.45.52
>                              Work: +32.2.655.44.85
>                              Netscape Conference Address
>                              Specific DLS Server
>   Additional Information:
>   Last Name     Ketels
>   First Name    Kris
>   Version       2.1

-- 
/**************************************************\
| http://www.xmlglobal.com  /* Corporate site */    |
| http://www.goxml.com     /* XML Search engine */  |
| http://www.cartnetwork.com /* XML E-commerce */   |
|   "Really Cool XML Solutions - available today!"  |
\**************************************************/