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