[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
An XML Namespaces Alternative...
Subject: An XML Namespaces Alternative... From: Tyler Baker <tyler@xxxxxxxxxxx> Date: Thu, 07 Jan 1999 14:12:45 -0500 |
I like many other XML and XSL developers are very dissatisfied with the most recent "Namespaces in XML" working draft. However, some people it appears think that the current draft is the greatest thing since sliced bread. Anyways, I am one of the people who actually liked the old namespaces PI based proposal, mostly because it was simple and did the job in terms of what a namespace is. The current working draft though I dislike for several main reasons: (1) Namespace declarations are declared using attributes. This forces programmers to explicitly use namespaces or at least handle the namespace attributes even if they do not want to. Some applications may not give a hoot about namespaces, but will have a desire to parse documents that are namespace aware without using some namespaces aware XML Parser API or filter API. SAX for example is not namespace aware, so building some complicated inefficient filter to handle namespaces on top of SAX really defeats the purpose of SAX in the first place (a de-facto standard that is supported in just about every XML Parser package around). (2) Validating documents efficiently can be a problem with some uses of "Namespaces in XML". I don't want to reignite the giant thread on this that popped up several months ago on xml-dev regarding this particular issue, but there certainly is not anything close to a concensus on what to do with DTD validation and namespaces. Since I am probably one of the noisier people on this list regarding this namespaces issue, I suppose it would be a good idea to put up or shut up. Simply complaining and moaning about why I or someone else does not like namespaces in XML does not improve things at all though it does release personal frustration. I suppose the only thing I can do is post to these lists an idea (call it an alternative) that borrows some ideas from the previous proposal as well as the current working draft (I am posting to XSL List because namespaces are a very important part of XSL). I hope that the fact that I am not a well-known SGML developer with 10+ years of experience does not preclude me from trying to inject some life into an issue that currently plagues XML and all of its children. I hope my comments are taken objectively and I don't receive too many ad-hominem attacks which seem to be all too common in the programming world when talking about technical matters (I as pretty much everyone else is guilty of this from time to time). Fortunately, these two lists are some of the most polite technical discussion lists I have encountered so far. Now I have spent some serious time thinking about this issue as it will be likely be very important that XML has an easy to use namespaces standard for an app I have spent over a year and a half on that uses XML extensively for all sorts of things. I don't need to use XML, but I feel it is for the most part simple, standardized, and easy enough for end users to handle manually for such things like user profile data and init files. I think there is a pretty good concensus now among XML and XSL developers that XML needs a namespaces mechanism, just that there seems to be much disagreement about what the namespaces mechanism should be. For the most part, I have heard a lot of negative criticism, and then criticism of that criticism on the latest draft, but I have heard of few public alternatives, so here is my attempt at taking a stab at XML namespaces. ----------------------------------------------------------------------------------------------------- In the previous XML Namespaces proposal (WD-xml-names-19980327) processing instructions were used to declare globally applicable namespaces. The core objections to this approach from what I could garner on xml-dev was mostly that the historical use of processing instructions (processing instructions are supposed to be application specific) suggested that you use processing instructions for things which are not supposed to be core to the document and optionally ignored by applications. For lots of different reasons, I think that namespaces should be optionally ignored but mostly because for most XML applications, namespaces are not necessary at all (they complicate things for the end user no matter how you cut it). The other objection to the last draft was the argument that the pi approach with global namespaces had no concept of namespace defaulting. Namespace defaulting if done cleanly, I think would be a great utility to xml users. However, the current draft I don't think does things cleanly. The approach I have here has namespace defaulting (which still of course has some problems with validation), does not need to use attributes and should work more efficiently with SAX since you do not need to interate through all attributes in an element or look up an attribute in a map of attributes to see if a namespace declaration has been declared. Also you can undeclare a namespace which is something that the most recent namespaces draft cannot do. This proposal I think should obviate the need for the DOM to have any special interfaces to handle namespaces and make it much more attractive and efficient to use in XSL since all you need to do in an application which uses the DOM is something like: switch (node.getNodeType()) { case Node.PROCESSING_INSTRUCTION: { // Handle namespace processing here } default: { // Do something else } } rather than something like this which is a lot more inefficient: NamedNodeMap attributes = node.getAttributes(); int length = attributes.getLength(); Node attribute; for (int i = 0; i < length; i++) { attribute = attributes.item(i); if (attribute.getNodeName().startsWith("xmlns:")) { // This is a special namespace node so handle namespace processing here } } A basic SAX filter that any programmer could use for namespaces (or they could write their own) would be something like public void startElement(String name, org.xml.sax.AttributeList attributes) throws org.xml.sax.SAXException { int index = name.indexOf(":"); if (index == -1) { // Look up default namespace } else { findNamespace(name.substring(0, index)); } } public void endElement(String name) throws org.xml.sax.SAXException { int index = name.indexOf(":"); if (index == -1) { // Look up default namespace } else { findNamespace(name.substring(0, index)); } } public void characters(char ch[], int start, int length) throws org.xml.sax.SAXException {} public void ignorableWhitespace(char ch[], int start, int length) throws org.xml.sax.SAXException {} public void processingInstruction(String target, String data) throws org.xml.sax.SAXException { if (target.equals("xml:begin-ns")) { parseBeginNamespace(data); } else if (target.equals("xml:end-ns")) { parseEndNamespace(data); } } private void parseBeginNamespace(String data) { // Parse urn, name, and priority and // push namespace onto namespace stack and // remove the current namespace if it is a // sibling of this namespace } private void parseEndNamespace(String data) { // Parse name, and remove namespace with the // given name (ns pi's must be nested properly) } private Namespace findNamespace(String prefix) { // Continually peek at namespaces on the namespace stack until // one is found and return the urn associated with // that namespace } There are already SAX filters for the current namespaces proposal (I think John Cowan who lurks on xml-dev wrote one), but they are inefficient because for each element you effectively have to search all attributes to see if one of the attributes is a namespace attribute. This in the general case will eat a lot of CPU. The only real-world alternative I can see is to not use SAX and do all of this natively in the XML Parser (i.e. for each parsed attribute check it there to see if it is a namespace declaration). SAX is very successful so I see no reason why anyone will use "Namespaces in XML" unless it is forced down their throats in forthcoming sister XML drafts like XSL. Anyways, here is a sample XML file that for the most part shows the basic implementation of my namespaces idea. <?xml version="1.0"?> <!-- This will push A onto the namespace stack --> <?xml:begin-ns name="A" urn="http://www.daisoft.com/schema-A"?> <A:foo> <!-- This will push B onto the namespace stack --> <?xml:begin-ns name="B" urn="http://www.daisoft.com/schema-B"?> <B:foo> <!-- This will push C onto the namespace stack --> <?xml:begin-ns name="C" super="A" urn="http://www.daisoft.com/schema-C"?> <C:foo> </C:foo> <!-- This will knock C off the stack and push D onto the namespace stack --> <?xml:begin-ns name="D" urn="http://www.daisoft.com/schema-D"?> <D:baz> </D:baz> <!-- This will pop D off the namespace stack --> <?xml:end-ns name="D"?> </B:foo> <!-- Right here the default namespace is B --> <bar> </bar> <!-- This will pop B off the namespace stack --> <?xml:end-ns name="B"?> </A:foo> <!-- This will pop A off the namespace stack even though this is not necessary since we are at the end of the document--> <?xml:end-ns name="A"?> Most of this is pretty self-explantory however there are a few not so clear things here. One is the "super" attribute of a namespace processing instruction. This could be omitted, but I thought it might be useful for object-oriented applications which need to delegate (perhaps instead of "super" it should be "delegate") processing of a content type to some other component. In other words for: <?xml:begin-ns name="C" super="A" urn="http://www.daisoft.com/schema-C"?> If an element type cannot be found in the namespace of "C" then it will delegate to the "A" namespace before throwing an error. This is just an idea that I think may help out object-oriented technologies so don't take it too seriously for the moment. You could even make it something like: <?xml:begin-ns name="C" super="B, A" urn="http://www.daisoft.com/schema-C"?> Where you would have multiple delegates. For frameworks like Coins, this sort of feature may open up a whole lot of creative possibilities for dynamically assembled applications (I am not speaking from the seat of my pants here as I have an entire GUI based application I have written which has most of its GUI glued together dynamically using XML and Java). Who really knows, but I think it is an avenue of exploration. I have not really looked into the negatives of this "super" attribute idea too much so please don't beat me up too bad if I have seriously overlooked something here. Other ideas I have are global namespaces, priorities and lots of other things, but my goal here is that the W3C produce a simple, clear, proposal that my fox terrier could understand upon a first read (-: Namespaces should be simple, so we should keep what comprises namespaces simpl. All in all, I think this approach is much simpler to implement (especially in scripting languages like PERL) and much easier to use than what is currently drafted. Most importantly, it does not use attributes which is one of the number one annoyances of the current draft. Of course this is all just my opinion, so hopefully this will start a thread of serious debate on what sort of namespaces mechanism we the developers would like the W3C to implement instead of us folks critical about the latest namespaces draft just complaining about it. Of course if the W3C totally ignores the needs to the non-member developers, it will lose a lot of credibility and respect that any standards organizations holds dear. I doubt the W3C is the ivory tower so many people claim it to be, so I guess solving this namespaces problem in the next couple of months will be a major test. Regards, Tyler XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: MSXML on NT4 Server - HELP, julian . burman | Thread | An XML Namespaces Alternative..., keshlam |
RE: MSXML on NT4 Server - HELP, julian . burman | Date | RE: Accessing values from another s, David Schach |
Month |