Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Namespaces Revisited...
 James Clark wrote: > Tyler Baker wrote: > > > > One thing which I find perplexing is that we are discussing how to add > > namespaces to XML when there are no real XML apps out there that I am > > aware of who have wrestled with this issue. > > XSL uses namespaces very heavily as does RDF. There are implementations > of both of these. WebDAV and P3P are other important users. There are > also important commercial apps that are coming out soon that make heavy > use of XML namespaces. > > James XSL is a technology on top of XML. It is not in and of itself an application which uses namespaces. RDF I am unfamiliar with and all of these commercial apps that are coming out that will make heavy use of XML namespaces are hard to imagine in that the latest draft (a major revision) is barely a month old and to date there have not been too many commercial apps to date that even use XML, only promises from a bunch of ISV's on the XML bandwagon. I think namespaces will be a very important part of XML, but on the implementation side of things as well as the end-user side of things (a lot of documents may allow user editing like in HTML) the current namespaces spec seems way too complex. My general rule of thumb is that if something is difficult for a programmer such as I to understand, it is hard to imagine that an average end-user will have a clue at all what is going on. If end-users have no idea what they are working with, we might as all just be doing markup in binary formats like the DOC format for Word. I personally am working on a client-side app which uses XML extensively for tasks as simple as init files to more complex tasks like saving object state. The attraction to XML is that the average user can hack around the architecture to get the settings they want. If XML is so complex that you need to have a masters in computer science to understand it, then there is no reason to use XML in my app as it is less efficient than some proprietary externalization format. The only major attraction to XML for me is that it makes the data my program generates much easier to work with for third party developers and end-users. Sadly enough, as the current namespaces spec is, it is very attractive to take out all the muckety muck XML inherits from SGML and define my own markup language which is simpler and easier to understand. If I do not find XML to be usable to third-parties and end-users, then I may have to make the decision to go another direction depsite the positive press XML has to date as well as its standardized reputation. I hope that will never be the case and that simplicity of XML can once again be a stated goal. In fact, another developer I am aware of uses his own markup format and is considering moving to XML, but he is finding it too complex for him to implement in his app. This guy is a quality developer, and even he is having problems with XML as it stands. HTML's main success was that it was very simple for the end-user; even my grandmother (when she was alive) could of learned it in a few short hours. If people code XML documents and then get errors from the application when it reads their data which says "invalid namespace declaration" or something like that, then they will obviously be frustrated. One thing I do when I write software that has intended third party uses is I always try and make the interface and usability of the utmost simplicity and usability. SAX's success to date I believe is based upon this notion of simplicity. The current namespaces spec is not. If people do not understand what in the world the spec means and what it is intended for in less than half an hour, then you need to ask yourself: "Does this make sense to the mortals". I know this is all common-sense BS which probably insults the intelligence of many of the people on the namespaces WG, but that is far from my intention. Perhaps a survey of poll of application developers as well as end-users on XML namespaces would help solve these sort of issues. Back in my college days at CMU there was a professor who was a CS/Psychology Nobel Laureate (I cannot remember his name off the bat) who taught there and lectured once on a very important lesson that I apply to my software development. Basically, that all things being equal people will choose not the most satisfying solution, but the most satisficing one. Satisficing is basically a term he invented which says that you choose the solution that makes everything (or everyone) the most happy. In other words, if you are searching for the holy grail solution to a problem, then you will likely never find it. If you choose a solution that you can prove will work as well as achieve its objectives and make everyone happy, then choose that solution. I think going back to the PI-based approach will be much more satisficing in the end than the current proposal. 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
|
|||||||||
