Namespaces Revisited...

[Tyler Baker]

James Clark wrote:

> Tyler Baker wrote:
> >
> > One thing which I find perplexing is that we are discussing how to add
> > namespaces to XML when there are no real XML apps out there that I am
> > aware of who have wrestled with this issue.
>
> XSL uses namespaces very heavily as does RDF.  There are implementations
> of both of these.  WebDAV and P3P are other important users. There are
> also important commercial apps that are coming out soon that make heavy
> use of XML namespaces.
>
> James

XSL is a technology on top of XML.  It is not in and of itself an application
which uses namespaces.  RDF I am unfamiliar with and all of these commercial apps
that are coming out that will make heavy use of XML namespaces are hard to
imagine in that the latest draft (a major revision) is barely a month old and to
date there have not been too many commercial apps to date that even use XML, only
promises from a bunch of ISV's on the XML bandwagon.

I think namespaces will be a very important part of XML, but on the
implementation side of things as well as the end-user side of things (a lot of
documents may allow user editing like in HTML) the current namespaces spec seems
way too complex.  My general rule of thumb is that if something is difficult for
a programmer such as I to understand, it is hard to imagine that an average
end-user will have a clue at all what is going on.  If end-users have no idea
what they are working with, we might as all just be doing markup in binary
formats like the DOC format for Word.

I personally am working on a client-side app which uses XML extensively for tasks
as simple as init files to more complex tasks like saving object state.  The
attraction to XML is that the average user can hack around the architecture to
get the settings they want.  If XML is so complex that you need to have a masters
in computer science to understand it, then there is no reason to use XML in my
app as it is less efficient than some proprietary externalization format.  The
only major attraction to XML for me is that it makes the data my program
generates much easier to work with for third party developers and end-users.
Sadly enough, as the current namespaces spec is, it is very attractive to take
out all the muckety muck XML inherits from SGML and define my own markup language
which is simpler and easier to understand.  If I do not find XML to be usable to
third-parties and end-users, then I may have to make the decision to go another
direction depsite the positive press XML has to date as well as its standardized
reputation.  I hope that will never be the case and that simplicity of XML can
once again be a stated goal.  In fact, another developer I am aware of uses his
own markup format and is considering moving to XML, but he is finding it too
complex for him to implement in his app.  This guy is a quality developer, and
even he is having problems with XML as it stands.

HTML's main success was that it was very simple for the end-user; even my
grandmother (when she was alive) could of learned it in a few short hours.  If
people code XML documents and then get errors from the application when it reads
their data which says "invalid namespace declaration" or something like that,
then they will obviously be frustrated.

One thing I do when I write software that has intended third party uses is I
always try and make the interface and usability of the utmost simplicity and
usability.  SAX's success to date I believe is based upon this notion of
simplicity.  The current namespaces spec is not.  If people do not understand
what in the world the spec means and what it is intended for in less than half an
hour, then you need to ask yourself: "Does this make sense to the mortals".

I know this is all common-sense BS which probably insults the intelligence of
many of the people on the namespaces WG, but that is far from my intention.
Perhaps a survey of poll of application developers as well as end-users on XML
namespaces would help solve these sort of issues.

Back in my college days at CMU there was a professor who was a CS/Psychology
Nobel Laureate (I cannot remember his name off the bat) who taught there and
lectured once on a very important lesson that I apply to my software
development.  Basically, that all things being equal people will choose not the
most satisfying solution, but the most satisficing one.  Satisficing is basically
a term he invented which says that you choose the solution that makes everything
(or everyone) the most happy.

In other words, if you are searching for the holy grail solution to a problem,
then you will likely never find it.  If you choose a solution that you can prove
will work as well as achieve its objectives and make everyone happy, then choose
that solution.  I think going back to the PI-based approach will be much more
satisficing in the end than the current proposal.

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/
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)