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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

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


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>

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

> Should this be discussed in this group or in another (e.g. Core Components, or Repository)?

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.  

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.
</additional_rants>

David Webber has a solution revolving around xlink in the dtd.  His
approach may be more sensible.


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!"  |
\**************************************************/


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC