[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Namespaces alternative? (was Re:WD for Namespaces 1.1)
Okay... so some people think Namespaces should become an integral part of XML. Some think that it should not. Some see no use for Namespaces, at least as far as their own XML involvement goes. Others see Namespaces as useful, but problematic. So... how about if we provide a alternative to Namespaces? After all, it is sometimes better to start from scratch than to Here is one idea... The way I view Namespaces is that it is a method by which one can mix multiple schemas that contain non-exclusive vocabularies. A namespace value can also be used as a method to identify a schema that a document conforms to. As a result, the concept of namespaces is tied more to schema definitions than it is to XML itself. So how about working Namespaces into schema languages instead of into XML? For instance, suppose you have the following two schemas (using a fictional language): <!-- URI: -//SchemaABC --> <schema> <element name="ABC"/> <element name="Body"/> <element name="From"/> </schema> <!-- URI: -//SchemaXYX --> <schema> <element name="XYZ"/> <element name="From"/> <element name="To"/> </schema> Now, suppose that you wanted to have a document that used some of each of the schemas. In order to do this with Namespaces, you might name each schema into a separate namespace something like the following: <abc:ABC xmlns:abc="-//SchemaABC" xmlns:xyz="-//SchemaXYZ"> <abc:Body></abc:Body> <xyz:From></xyz:From> <xyz:To></xyz:To> </abc:ABC> On the other hand, suppose instead that you were to create a third schema that looked like the following: <!-- URI: -//SchemaABCXYZ --> <schema> <include URI="-//SchemaABC" preface="abc:"/> <include URI="-//SchemaXYX" preface="xyz:"/> </schema> Then an XML document might name the schema as follows: <abc:ABC xmlns="-//SchemaABCXYZ"> <abc:Body></abc:Body> <xyz:From></xyz:From> <xyz:To></xyz:To> </abc:ABC> So far, what we have effectively done is grouped multiple schemas into a single schema and thereby reducing the namespace to one at the document level. Now, a more robust implementation of a schema might look more like the following: <!-- URI: -//SchemaABCXYZ --> <schema> <include URI="-//SchemaABC"> <exclude-element name="From"/> <alias-element name="ABC" alias="myABC"/> <!-- Body element is being used as-is. --> </include> <include URI="-//SchemaXYZ"> <exclude-element name="XYZ"/> <alias-element name="From" alias="Sender"/> <alias-element name="To" alias="Recipient"/> </include> <element name="Timestamp"> </schema> With this, the document might look like the following: <?xml version="1.1" schema="-//SchemaABCXYZ"?> <myABC> <Sender></Sender> <Recipient></Recipient> <Body></Body> <Timestamp/> </myABC> This method does not break DTDs (as far as I can see). It also gets rid of the need for the XML Namespace mechanism. If someone still wanted the namespace-style names, they could alias any that they want to use. On the other hand, I can foresee some setbacks as well. I also realize that the above examples are not necessarily the exact way things should be done or that the above concepts are all-inclusive of what is needed within such a concept to make this work. This would be an opportunity for the community to come up with something (assuming the idea even has enough merit to start with). Some questions I can think of are: 1) How easy or difficult would it be to add this concept to existing schema languages? 2) Could a common XML syntax (as shown in the last example) be used regardless of the actual schema language used? 3) What would this mean from a performance point-of-view? Well, let's hear it. Is this workable? Or is this just my total misunderstanding of the problem? --- Seairth Jacobs seairth@s...
|
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
|