[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: A multi-step approach on defining object-oriented nature o
I don't disagree with that, Aaron. I do work in production where the majority consensus is to ignore namespaces. That worked fine for some of them until the namespace for XSLT changed, they ignored it, a customer now demands that the current namespace be used, and a whole lot of XSLT fell over dead. They are blaming guess who? MS. It isn't the rightness; it is the perception. No MS probably can't fix it unilaterally, but my point was, many of the affected are not W3C members and therefore cannot fix a private property. See the deepening problem of the private community wresting control of public standards processes. They have also accepted by that act, the responsibility to ensure they work. What happened? Simple. The spec says the namespace is a syntax device for disambiguating names. It doesn't say why one does that and doesn't care. In implementation, the namespace string is determining what functionality is in effect (yes, it is silently tied to semantics). Who's problem is that? From the production users' viewpoint, the vendor who sold them the software. And no, unless they are really desperate, they won't read the spec and particularly if that spec does not reflect their working world correctly. Remember... running code? I don't know what action they should take either. SGML didn't have this problem because it didn't have aggregation capability in the SGML syntax (well... subdoc and PE hacks). I believe they should think long and hard about the myths of Internet Time and be moderate about adoption. But to be fair, we are all on a learning curve now. We've never had a beastie this big to drive before. len From: Aaron Skonnard [mailto:aarons@d...] > Len wrote: > > That's nuts. No sane vendor requires their production users > to read specifications to figure out why the vendors' products > don't work right, and no experienced manager blames the > specifications. Sure they do. When the problem space is inherently complex, how simple can the solution be? Learning the specifications is part of working in the problem space and organizations everywhere pay hefty bucks to educate their developers towards that end goal. I remember in the early days of MSXML's XPath implementation, you could evaluate an XPath expression without prefixes (e.g., /foo/bar/baz) against a namespace-qualified document (using a default namespace, no prefixes) and it would actually identify the elements. So even though this seemed like "it worked" to the user, it was actually broken wrt to the XPath specification. Microsoft can't simplify the namespace madness without contradicting the layered specifications, annoying the rest of the industry, and being accused of anti-open/standard practices. > They accept the responsibility to fix the problem. That assumes they CAN fix the problem. > Get this through your head: <strong>They Blame Microsoft.</strong> > It is YOUR problem. It's everyone's problem. It would sure be nice to see the W3C take action along these lines.
|
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
|