xml-dev - Re: Another errata?

[Tyler Baker <tyler@infinet.com>]

Mark Birbeck wrote:

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

OK sorry for the misunderstanding here.  I guess I took your words out of context...

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

I guess this is less a matter of arguing objective facts anymore and more of a value-judgement
now among people who find that "Namespaces in XML" is easy to understand for them and those
who either find it hard to understand, or else feel it will be hard for novices to
understand.  It breaks down to a personal judgement call here.  Nevertheless, I think it is
clear that "Namespaces in XML" has not been a concensus building process.

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

Most DOM implementations that have namespaces support (Oracle's and SUN's are two that come to
mind) do preserve the prefix information inherently (I am not sure whether QNames or expanded
names are returned from calls to getNodeName() though).  Some people here were arguing that in
SAX 1.1 or whatever, that this prefix information should be lost because only the "namespace"
should be relevant to the application.  A lot of people seemed to agree with this point (I
didn't as I favored parsers showing the application a Name type which could resolve prefixes
and namespaces) that all you need to do is present the expanded name to the application.  I am
really confused here more than ever as to what on earth "Namespaces in XML" and those that
support it are trying to accomplish with it more than ever.

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

There is a stark difference between research oriented development and business oriented
development.  In universities you will find that most CS professors are versed in all kinds of
programming languages, some of them in-house ones they help to develop. They get paid to teach
and do abstract research for the most part (sometimes they get grants from industry but even
those grants deal a lot with abstract research).  Whether anyone actually understands what
they are doing is not relevant until they stumble onto something useful.  Once they stumble
onto something useful, then they may patent it or publish it or whatever they feel is
appropriate.  In the end, industry will take these ideas and try and apply this research to
real-world problems.  If things are too hot to handle and cost too much to develop, maintain,
and support, any products resulting from this research will likely have a very small market.
Is this what people want XML to be suited for:  a very small market.

I don't consider XML to be something that should be rocket science as its intended audience
should be average developers.  The number one goal I feel should be to have a simple markup
language that more complex solutions can be built upon.  "Namespaces in XML" makes building
complex solutions harder because supporting all of the weird semantics of it is not easy to
handle.


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

So should XML only be used by CS graduates?  I sure hope not.  Only about 10% or less of the
entire IS industry is comprised of CS graduates.  Should XML be relegated to geekdom or should
it be something to bring the entire web together?  I favor the latter as the web is made up of
millions and millions of people, 99% or less of which have no programming experience, yet want
to have control over the content they create.  If the W3C screws up XML (like it seems to be
doing with "Namespaces in XML", the entire web will be stuck in HTML land for the next 5
years.

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

Again XML is not rocket science.  You can use it to do some very basic things or else you can
get creative with it.  Is the intention here to make XML as non-understandable by the masses
as possible.  This logic suggests this even though I am pretty sure that is not your intention
here.

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

Simpler specifications allow for less need for educating (because they are more direct and to
the point) and more time others can devote to more creative endeavours.  And on the flip-side
if you have a great tool for doing all of the trivial tasks of the web, why screw it up?

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

Understanding through dictation is far different than understanding something and being able
to build on it.  Some major advances in physics have come about since Einstein's death, but
only a very small number of people on earth can do anything useful in terms of building upon
Einstein's work.  The last thing Einstein was working on was a simple formula for explaining
in simple terms how the universe works.  He never got that far, but even Einstein realized
that

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

No I am saying that you either have concensus on what works the best and not try and just
create something that makes everyone "feel good" but does not solve the ultimate problem.  If
you publish something called a standard, but it does not do the job, then you basically have
nothing but a glorified piece of paper with a bunch of names on it.

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

It depends on your problem domain I suppose.  Millions use Visual Basic, even though some
would hardly consider it a programming language.  Yah Java does not do everything it promises,
but I feel it does 95% of the stuff most developers need for most applications.

Tyler


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)