OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] A multi-step approach on defining object-oriented nature o

[ Lists Home | Date Index | Thread Index ]

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@develop.com]

> 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.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS