xml-dev - RE: Another errata?

[Mark Birbeck <Mark.Birbeck@iedigital.net>]

Tyler Baker wrote:
> Mark Birbeck wrote:
> > 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.

I mean the words used are tricky, because namespace is used to mean
'real namespace' and 'XML namespace' interchangeably. But the context
usually makes it clear which is implied. I'm *not* saying that using
namespaces is tricky. Actually it's pretty easy.

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

Yep. So how isn't it? Seems to be pretty real-world to me.

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

Why would you not preserve the prefixes? This is a bizarre point. If I
delete the contents of my hard-drive shouldn't my word processor still
open my letters? Of course not. As it happens, you couldn't delete the
prefix anyway, because they are part of the names of the elements and
attributes. Think of it like an XML 1.0 document - would you delete all
characters before a colon in all names? Of course you wouldn't.
Effectively you have an XML 1.0 document that conforms to the namespace
spec if all 'Names' actually conform to 'QNames' (or in some cases
NCNames). All that happens with namespaces is that you have an
additional way of viewing your nodes over and above that defined in XML
1.0, and that is by namespace.

> I suppose
> the people in the "Namespaces in XML" feel that once you read 
> in a document, you throw it
> away.

They also believe the moon is made of cheese.

> 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 

If all you ever develop is things that can be understood by the average
developer then this discussion group would not exist since XML would not
exist, and nor would space travel, electricity, and just about every
philosophy ever invented.

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

Compiler technology is understandable today by most computer science
graduates, as is XML. Yet does anyone remember trying to follow what the
hell the guys at AT&T were up to with yacc (Yet Another
Compiler-Compiler) and so forth. In fact teenage computer science
students will be happily dealing in XML namespaces in two years time.

And why should XML be understood by end users? Compiler technology isn't
understood by most people who write C++ and Java programs. When my
clients use Microsoft Office 97 they don't want to understand the file
format. Why should that suddenly change when they use Office 2000? Sure,
*I* want to understand the file format so I can do things with it, but
that's my job. I also need to understand point-to-point tunnelling
protocol, active directory services and domain name servers -
unfortunately more than your 'average developer'.

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

Lovely. But I could equally say that the people who come up with the big
stuff can obviously produce better things than those who have to be
helped to understand what they've produced. They should therefore spend
more time developing and less time explaining. Of course I wouldn't say
that ... but by your criteria of efficiency I would be perfectly
justified. In fact it has to be a bit of both - developing and educating
- but my central point is that the standards writer is not responsible
for take-up. It's great if they get involved - like some do on this list
- but it's not an obligation.

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

Seems to me that actually each generation simplifies what its ancestors
produced. And then its the next generation who truly benefit from that.
Nobody simplified (or complicated, depending on your standpoint (-:)
Aristotle, Hegel, Marx, Einstein, Freud, and so on, in their own
lifetimes. Yet today, most physics students can easily understand
Einstein's theory of relativity.

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

Very profound - but what are you on about?

> Compromise on technical matters is
> one of the worst things you can do.

So why do you want understandable standards? Surely if you're against
compromise you don't want *any* standards?

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

An evangelical approach, I think. I know Java and C++, and many other
languages. I think Java is great, and definitely one of the nicest
languages yet to be devised, but still I don't use it. And that's after
a great deal of evaluation. Essentially it promises what it can't
deliver. Anyway, I think you have to allow people credit for coming to
serious conclusions, even if, as may sometimes happen, they disagree
with you.

>  If you write some spec without regard to simplicity 
> you are falling into a similar
> 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".

If someone wrote a book on namespaces and it was difficult to
understand, then I would agree with you that it was a wasted effort. But
a standard submitted to W3C? It *has* to be terse because it is being
examined by numerous experts, who as far as I can see do *not* waste
their time strutting around pretending the world is stupid. (Even if
they did, I'd still thank them for XML, namespaces, XSL, XLink, HTML,
HTTP, etc., etc.)

I'm not quite sure why I'm getting so worked up about this, particularly
given the lack of intervention by the standards writers themselves in
their own defence! Maybe it's because over my 16 years in the business
I've realised that the things that you learn yourself you *really*
learn, and the people who are prepared to struggle to understand
difficult concepts are the people you really want around you. We are
lucky to be of the same generation as the innovators. *We* are getting
the benefit of *their* developments, yet you are taking the attitude
that you're doing *them* a favour by using their ideas!


Mark Birbeck
Managing Director
Intra Extra Digital Ltd.
39 Whitfield Street
London
W1P 5RE
w: http://www.iedigital.net/
t: 0171 681 4135
e: Mark.Birbeck@iedigital.net


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)