[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Next Round
david@m... wrote: > Tyler Baker writes: > > > First, we will need to define a new type, namely Name. > > > > public interface Name { > > String getPrefix(); > > String getLocalName(); > > String getQualifiedName(); > > String getNamespace(); > > String getExpandedName(); > > Name clone(); > > } > > [...] > > I proposed something like this early on as well, but have since backed > away from it. I like to keep SAX very dumb and low level, so that > other APIs (like SAXON or MDSAX) can build on top of it with little > constraint. I agree totally with you except for the fact that namespaces automatically makes XML no longer dumb or necessarily low-level. The main reason for this suggestion is that the alternative is for applications to manage namespace processing themselves or else dump some filter on top which may add major inefficiencies. Before making any judgement on this regarding MDSAX or SAXON, I would ask Michael Kay and Bill la Forge what they think about a Name type and anyone else who has written some higher-level API's for XML (this includes DOM implementors). I know that with an XSL Processor I have been working on which has SAX support for building the stylesheet tree, a specific Name type would help out alot in implementing the "Namespaces in XML" parts of constructing the result tree. Another major reason for doing Names this way is that for objects (perhaps beans) may have no global idea of what the current namespace they are to be applied to. If you attach a Name type, when spitting out XML you can automatically construct the namespace nodes (attribute namespace declarations) as needed (note, I am not speaking about XSL right now). Of course you can do all of this on top of SAX, but it may be inefficient and certainly very much unnatural for developers using SAX in applications to handle. "Namespaces in XML" is complicated enough as it is so I feel that making an effort at simplifying things as much as possible for the end user would do a great deal of justice in presenting something so complicated to handle in a simple way. Last but not least, for DOM implementations that are built with SAX and may have proprietary namespaces support (don't know when or if the DOM will have any kind of namespace awareness in the future) it would really help these folks out a lot. Docuverse SDK would be just one off the top of my head. The point here is that pretty much anyone who uses "Namespaces in XML" (which I feel will likely be less than 1% of the XML user community in the future if even that high) will have to deal with the myriad of problems that "Namespaces in XML" creates one way or another. I would prefer to try and remove as much complexity from the application developer as possible so that using "Namespaces in XML" will not be too much of a pain (most people I don't think will accept the toothache and instead stay away from "Namespaces in XML" altogether). Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
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
|