Another errata?

[Tyler Baker]

Mark Birbeck wrote:

> Ronald Bourret wrote:
> > That this is confusing is evident from the above discussion
> > -- John means
> > XML namespace and Mark means traditional namespace.
>
> I'm not confused thanks - I mean both. I am drawing a distinction. You
> need both to understand how the namespaces spec implements 'traditional
> namespaces' in a manner useful to XML. In short, one, traditional
> namespace would not be enough for XML because you lose structure. It
> therefore needs a lot of them, and this is achieved by having
> effectively a 'namespace container' full of other (real) namespaces.
> That namespace container is an 'XML namespace' - which for brevity, we
> call a 'namespace'. (Hey, I'm not disagreeing with you that it's
> tricky!!)

Not only tricky, but unnecessarily tricky.  XML should be a tool for real-world business
solutions, not something that is more or less a puzzle some CS professor designs for his
students.  Namespaces is a pain to deal with no matter how you look at it.  Once you read a
document into memory and no longer preserve the original prefixes (or rather the QName), when
you write the document back out (which has possibly been mutated) where do you get these
prefixes?  Do you simply invent them in the form a, b, c, ..., aa, ab, ac, ... etc.  I suppose
the people in the "Namespaces in XML" feel that once you read in a document, you throw it
away.  Under the old PI-Proposal it would be trivial for an XML API to allow the user to
assign a prefix to a namespace before writing out an XML Document.  Now it is far more
difficult and practically impossible to deal with at the application level in a manageable way
for the end-user.  I suppose only parsing matters anymore with respect to XML and writing out
XML documents no longer matters.  This is sad as it effectively makes XML useless for my needs
in an application I have.

> > > It is not the job of standards
> > > developers to make sure we understand everything they write. ...
> >
> > <soapbox>
> > Huh?  It most certainly *is* the job of the standards
> > developers to make
> > sure we understand what they write.
>
> I suppose we're onto matters of opinion now, but a standard must be
> unambiguous in its *formal* interpretation. I may read it and
> misunderstand, but when I get down to the nitty-gritty of
> implementation, provided that I eventually *do* understand it, I should
> be able to do this unambiguously.
>
> If you describe 'intent' then what if you do not cover a usage that
> later arises? You introduce ambiguity.

If people cannot understand what you write because the ideas are too complex for the average
developer, then there is no real point in having a standard in the first place because all
that ISV's will be doing is commoditizing their products for a niche market and overall this
will reduce innovation in the marketplace.  In the end everyone loses here.  However, for
broadly adopted technologies, standards are very important for application to application
interoperability which is something end-users clamor for.  But if things are too hard to
understand because either the concepts have not been simplified or else the designers of those
concepts don't care about clarity, then this does no one any good.

> > In contrast, the namespaces spec *is* widely misinterpreted,
> > and by people
> > who, judging by their posts to this list, are intelligent and
> > more than
> > willing to read, re-read, and re-re-read specs.  To me, that
> > says there is
> > something wrong, and I think a good example of this is the
> > fact that the
> > spec repeatedly leads the reader to believe that unprefixed
> > attributes
> > belong to the namespace of the element.
>
> The spec does not! The reader's mistaken assumptions about what the
> namespaces spec is trying to achieve leads them to read this into it.
> But if we're really honest here, if we were in a discussion group on
> compiler technology ten years ago, you would not have such a wide range
> of people discussing these issues, and narrower range of
> misinterpretation (I'm not saying everyone understood everything then
> either). That's not to say we shouldn't have more people involved, but I

That is because compiler technology is a totally different field (and much more complex field)
than XML will ever be.  If XML is to be used by only developers and end-users who understand
compiler technology then it will fail miserably no matter how much hype is in the presses
these days.

> disagree with this 'dumbing down' attitude that seems to exist, where we
> must ensure that everyone can understand. If you want to write a book
> making it clearer then do it - we'd all probably be grateful - but the
> spec itself MUST be a formal document.

I don't know what your definition of genius is, but mine is simple "the ability to simplify
the complex".  Quite plainly, if you can make reduce the learning curve for our feeble human
minds to understand, it will take less time for people to learn those concepts and they can
then take the time they have saved and work on new and interesting tasks.  If every generation
has to spend most of their adult life just learning everything that the previous generation
created (but did not simplify) we will never have progress because human beings will be very
old and very grey before they ever get the opportunity to even think original thoughts.

> > I think a mistake made in writing many specifications is to rely on
> > excessively formal language and write down only the rules, not the
> > motivation.  In my mind, the point of a specification is not to write
> > rules, but to get everybody to agree to the same rules.
>
> No! The job of the discussion *about* a spec is to find agreement. Once
> that has been arrived at you need to codify that in a way that is
> unambiguous. It needs to be as formal as possible!

If everyone told you to jump off a cliff would you do it?  Compromise on technical matters is
one of the worst things you can do.  I personally feel you should let everyone come up with
their own implementations and let public opinion and the marketplace decide who is the best.
Compromise usually (but not always) creates groupthink and an atmosphere that very sub-optimal
decisions are OK "as long as we can all just get along".

> > Finally, if you are driving a technology through standards
> > (as opposed to
> > the other way around, which is more common), then, whether
> > you like it or
> > not, those standards necessarily play a role in marketing
> > that technology,
> > and the more accessible those standards are, the more likely
> > the technology
> > will succeed.
>
> I don't think that is the job of standards. Others can write books on
> it, produce training courses, and as you say, get hamsters involved in
> video production (although I believe that's illegal in some States) but
> the standard itself must be as terse and precise as possible.

You think people read all of these books and take these training courses because they want
to?  They take them usually because the technologies they use today are dictated to them.
Java's success is an example of people writing code in Java because the "wanted to" because
Java took out 85% of the pain in C++.  Nevertheless, I have plenty of friends who still write
C++ code on new projects using MS Visual C++ because "old grannies" at their institutions
think everyone should be doing things they way they did them 10-15 years ago.  They can't see
the benefits of Java being a simpler version of C++, because they have not made an effort to
do so.  If you write some spec without regard to simplicity you are falling into a similiar
model.  "Namespaces in XML" is a pure example of simplicity falling to the wayside in favor
of  the attitude "well if I can understand it and no one else can, then the whole world is
stupid".

I think this will change in the next 10 years as people will become fed-up with any company or
standards body that does not make a genuine effort at creating simple solutions from the
get-go, especially since the trend in business these days is to be leaner and meaner.
Microsoft has been eating up the small to medium sized business market with NT because they
produce simpler solutions to SUN and IBM even though their OS's may crash all of the time.
Even though their customer base is for the most part may be unhappy with their products,
finding MS Solution Providers is a lot easier (and cheaper) than finding UNIX engineers.
Recently companies like SUN and IBM may be getting the drift, but it may be too little too
late.  But then again, MS is seemingly doomed to fail big with NT 5.0 (managing 40 million LOC
in one build is just plain mind-boggling) so who knows.  I just know that my faith in the W3C
would be seriously rekindled if "Namespaces in XML" were ripped off the W3C website right now
and they started over with a more open-process to create a more well-thought out solution.

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)