[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Namespaces - a couple nits and questions
[Danny Vint] > Questions: > > Q1) I have 3 different standards within our organization and they may have > the same elements and some of the same structures. How should namespaces be > used to identify these particular standards? Should I have one Insurance > domain namespace? > I think that, if you have a fairly distinct group of structures or types with some coherence, that it makes sense to give it a distinct namespace. This would especially apply to your common (reusable, I presume) elements and structures. You can import them (into the distinct namespace) into the other schemas. At work, we have been working on a schema for Advanced Traveler Information Systems. It imports about four or five other schemas to get various capabilities, such as location referencing and event reporting. We gave each of those pieces their own namespaces, but the top-level schema does not have its own namespace. So far, we have not come up with a convincing reason to use a namespace for the top-level elements. If we thought it might be imported by some other schema, we probably would, but that does not seem likely right now. In our case, the other parts are developed by other groups rather independently, and each having its own namespace makes it really clear that an independent module is being developed and imported. So far, this plan seems to be very satisfactory. I admit that we might rethink whether the top-level schema has its own namespace or not. Here is an example of (part of ) an instance document: <origin refID="ID2-1"> <id>F14B011A9D0D</id> <name>State and Division</name> <location> <!-- Contains elements from the "lrms" namespace --> <lrms:crossStreets> <lrms:onStreetName>State St.</lrms:onStreetName> <lrms:fromStreetName>Division St.</lrms:fromStreetName> <lrms:cityName>Chicago</lrms:cityName> <lrms:state>IL</lrms:state> <lrms:country>USA</lrms:country> </lrms:crossStreets> <!-- End of "lrms" elements --> </location> <pointRole>origin</pointRole> </origin> > Our standards are currently divided along the lines of Life, Property, > Causality and Surety, and Reinsurance, should I have different namespace > for each? At least one of these specs has been split into 2 parts, one > being the payload (business/Insurance data) and the other being a framework > or messaging structure that includes the payload portion. > > Should this be all one namespace or should they be at least 2 namespaces? > Should the included portion be identifiable by 2 namespaces (one namespace > being when used standalone and the other when used in the message structure)? I would not identify them differently just because they are used in different contexts. I also do not think that you need two namespaces just because there are two distinct parts to a message. But if there is a common, reusable core, there might be a case for its own namespace. On the other hand, as I said above, that seems to me to make the most sense for schemas that are really independently developed, especially if it is by another organization. > > Q2) Should a namespace be versioned? This is more for file and element > identification which fits #1 and #2, but seems contrary to #3. > I think we need a best practice for versioning, and although it has been discussed here there has been no consensus yet. I think namespaces should not change until the new design instances will seriously break processing anyway (since changing namespaces is practically certain to break processing). So there needs to be some other versioning convention. > Q3) Should a namespace act like a PUBLIC Identifier and be able to identify > a specific file and version of a schema (lets ignore DTDs for now)? This > doesn't mean that I would be able to look up the URL and find the schema, > but that there should be a unique name/namespace for each version. > Not for versions unless they are major changes (see above). For the file, you do have the SchemaLocation attribute, so you can use that for the purpose if you like. Another point to be considering is extensibility. In the ATIS schema, there is a ***lot*** of desire in the industry to allow local enumerated values (read: code values). Of course, you can allow any string or number for enumerations, but then you cannot validate that part of an instance. I have been experimenting, and what looks really good is to have a separate schema (with its own namespace) for local user extensions. Only this extensibility is allowed to be extended (we see no need for restrictions in this work). Model groups in the extensibility schema work very well, acting much like parameter entities in DTDs. It is possible to seamlessly extend enumerations and still validate the instances. Of course, with this approach you cannot have two independent extensions that have name collisions. Model groups also seem to work well for adding new elements into a structure. You have to restrict these extensions to specific types of elements, but that is a good practice anyway. If anything anywhere can change, what good is a schema? With this approach, and with the right declarations in the top-level schema, you can extend your enumerations and even element structures without touching the top-level schema at all, just by adding to the extensibility types in the extensibility schema. You could mark everything "final" in the top-level schema and still do the anticipated extensions. In real applications, it seems that customization can be quite important. We have not tested this approach that much yet, but it looks very good so far. Cheers, Tom P
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|