[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SAX Filters for Namespace Processing
Tom, ... I don't know many other 'users' who are also producing > specifications for things such as resource definitions, access control, > etc. I am also an exception to the rule, except that I am involved in a > project where the needs of my users are something I deal with > constantly. For quite some time, dbXML didn't have support for XPath > namespaces, and it wasn't requested until a few weeks ago, and by only > two people out of quite a few. I am certainly sympathetic to your viewpoint, and strongly agree that we need to keep XML as simple as possible. As we say "code talks". On the other hand, I also think that XML Namespaces has gotten alot of undeserved flak, primarily because it introduces a few new ways to shoot yourself in the foot, but on the other hand, the resultant hole in the foot is no larger than can be made with e.g. enternal parsed entities etc. The main thing that XML Namespaces provide is not a simple partitioning of names (booring!) rather a mechanism _by which_ XML can be better integrated with the web (via URIs). Of course XML Namespaces makes no mention of this but of course that is the whole point of RDDL, and so if XML namespace names are seen and used as _URIs_ not merely unique names, we have something that's actually useful. Of course the XML 1.0 link to the web is via a system identifier and external entities (choke!) so I see namespaces actually as an overall simplification rather than added complexity. > > > For example: XSLT. Hard to use it without using namespaces, eh? > > An unfortunate biproduct of defining XSLT as an XML grammar. As an XML > grammar, could it have been done without namespaces? Sure. And again, > I'm not against namespaces, I'm against their abuse. I don't really > like the mechanism itself, but a namespacing system is necessary for > some cases. Sure, and of course namespaces and XSLT might have been implemented differently. But see above. Similarly XPath might have been implemented differently but that's a done deal, and (IMHO) you are best to implement it _as is_ in all its glory :-) As a -user- of XPath, I didn't expect that I'd have to request namespace support in an implementation, just as we might argue that English is not designed in a logical fashion, I happen to know it and aren't sure that I'd ever getting around to learning or using the 'fixed' version. > > > Shrug. The EDI folks are looking pretty closely at XML. > > Yes, I know. I was one of those EDI users. The simpicity of XML is > what drew me to it. And you are exactly correct that the _mere use_ of XML does not in any way ensure that the system will be properly designed. Certainly something of arbitrary complexity ... even monstrosities ... might be built on binary logic, that doesn't mean binary logic is not itself a good thing. > > > Shrug. I suspect that alot of carpentry _businesses_ will be > using XML in > > some form or another (hopefully unbeknownst to them!!) in > several years or > > so. > > That's if XML survives the backlash that will definitely come if the > bloat continues at its current rate. > Specs come and go. I think XML will succeed in the long term, I don't think all of the XML related specs will succeed. I'm not sure that the so called XML 2.0 will ever get done correctly, and if done incorrectly wouldn't bet that it will come into widespread use (barring of course something like XML blueberry which when Khmer becomes the dominant language of Earth something in this later millenium, might actually become quite useful :-) So in generally while there is alot of yada yada yada discussion related to XML it is something worth getting right. -Jonathan
|
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
|