[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]
Powered by eList eXpress LLC