xml-dev - XML-DEV (was Re: YAXPAPI)

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

In replying to Don I'm taking the opportunity to re-iterate and refine some
ideas about the role of XML-DEV.

Thanks Don,

	I think I know how you feel and will try to address it.  There is no
suggestion that your ideas are not valuable. Since I try to develop this
list as a collaborative communal arena, I'll outline my underlying ideas.

	There is only one formal route for XML discussion - XML-WG, with about 10
members chosen from the W3C. They are supported by a larger virtual body of
about 100 experts (XML-SIG). The WG asks the SIG to consider proposals for
XML and related things (XLL, XSL), listens very carefully to what the
XML-SIG says, makes changes, and has regular votes to firm up on the spec.
This culminated in last week's PR.

One of the important ideas of XML was that it should be *simple*. Design
goal 4 in the spec is:
"It shall be simple to write programs which process XML documents".

This was exemplified by the 'Mythical CompSci grad student' who could hack
a non-validating XML parser in 2 weeks. [This person is still quite
mythical :-)] There has also been assumption that the 'desperate Perl
hacker' (DPH) is an important feature of the emerging XML scene. This
person doesn't necessarily use XML tools to manage XML documents - if they
wanted to change a tag they'd just use:
s/<FRED>/<SUE>/g
and most of the time this type of approach works.

I was invited to be part of the XML-SIG although I am not an SGML expert
and have never read 8879.  My role has emerged as representing the DPH (or
worse). I have been described as a 'bellwether' and a Dumb XML Browser
Hacker in both of which I take pride as it legitimises my self-appointed
role.  This is, very simply, to represent the 99% of future XML users who
know nothing about SGML, objects, DTDs, parameter entities, etc. BUT who
(at least in my vision) want to be more than passive consumers of
shrink-wrapped systems. I felt that HTML (actually HTTP) was an enormous
liberating force because it allowed people to publish for the first time.
The great success of HTML was that anyone could play - you could create
HTML documents after a few hours' experimentation. It was easy - we have
discovered that ease has its price - I feel it's an acceptable one.  XML
also has the capability to make publishing available for 'everyone', but
only if it is made simple enough to be a self-replicating idea ('meme').

So I - as 'webhacker' - have consistently argued for simplicity in XML. At
the other end of the spectrum are SGML experts who want XML to provide WWW
support for any current SGML application. The WG has to find a practicable
way forward, and we are accustomed to 'disappointment'. Personally I think
XML is too complex and too difficult to understand - I have made my views
known here :-) [I have argued for the removal of dual quoting,
<![CDATA...]]>, NOTATION (which I *still* do not fully understand). I have
argued that the WG should address whitespace more proactively. I have said
that XLL is too abstract and needs further elaboration.] I know that the WG
considers all suggestions and perhaps 1% of what I say has some effect on
the final spec. I'll settle for that.

It has been made very clear that the WG will not address implementation
issues. They understand them, and make decisions based on them, but they do
not want to constrain how people use XML. I applaud this, because XML will
not be the vision of what its creators have now (in 1997) but the
accumulated experimentation of the world over the next few years. What the
WG has addressed is a language which is both robust and flexible - two
extremely difficult things to bring together. I am sure that everyone
involved in the XML process thinks "they have got bits wrong" but we are
all prepared to work with what emerges.

So - to XML-DEV. There is a clear vacuum between the spec and working
applications of XML, and XML-DEV was offered as a way to fill it. It has no
formal status - it's supported by the goodwill of Henry Rzepa and myself
(both molecular scientists - Henry does theoretical calculations on
molecules and my 'day job' is to help people learn how to design new
drugs). We have a not very hidden agenda in wishing XML to prosper, but we
feel we represent an average vertical XML community in the future.  

Personally I find SGML very hard. Perhaps this is because I don't use it
every day and because I think in concrete terms (being an experimental
scientist). Words like 'entity' do not bring immediate enlightenment. I do
not fully understand XLL, I do not understand groves, I do not understand
formal design of interfaces, I do not understand the DSSSL spec, I do not
(at least yet) understand the DOM. But I represent 99% of future XML users.
I do not feel I and others should be disenfranchised - that may be
unrealistic and Quixotic, but at least I enjoy the windmills.


In setting up XML-DEV I assumed that lots of people would be developing
software (initially prototypes) for XML, and would need a discussion forum.
I've been surprised how little software there has so far been. Not
disappointed - I'm never disappointed in the virtual arena - what happens,
happens.  But personally I think the ratio of talk to action is too high -
maybe that's my scientific background.

I get a small amount of private mail that suggests that XML_DEV has a
useful role, and that continuing to highlight the simple approach is
valuable.  There is also general support for a public collaborative forum.

My ideal is to see communal activities arise out of XML-DEV - rather like
the tcl, Linux, LaTeX, Perl and other efforts. I see the WWW as a
biological system - lots of new species evolve and only a very few survive.
Not always the apparently 'best'.

We've had several goes at creating an API on this list. Take it as
axiomatic that everyone has slightly different ideas - some are radically
different. We catalysed the formation of Xapi-J (from John Tigue) -
unfortunately no-one uses it because (I think) they are all waiting for the
DOM. I am too impatient to wait for the DOM I am revising JUMBO and want to
get out the next snapshot.

Those of use who have written simple systems feel we have an urgent need to
rationalise their interfaces. What we (or at least JUMBO) don't want is yet
6 more incompatible parsers.  We believe that this is achievable in a short
time. If so, it will give impetus to the communal approach.

History will tell whether this is valuable :-)



At 16:38 13/12/97 -0800, Don Park wrote:

[...]

>First, I do not see the need for simple API.  Having a simple API now will
        ^^^^^^^^^^^^
I do. Remember, I'm Dumb :-)

>definitely help control propliferation of proprietary XML parser API but, in
>the long run, it will restrict application programmers to the set of
>functionalities supported by the simple API.

There was never any suggestion it would be the only API.  Let's assume
there are 3 APIs.
	- simple
	- Object based
	- grove based
JUMBO uses the first. If someone says "I would really like JUMBO to sit on
top of groves", I will appeal to the world for someone to have JumboGroves.
[JUMBO is offered as a public communal project.] If no one comes to the
party, too bad :-)

>
>Second, the cat is already out of the bag.  For example, MSXML is already in
>IE 4.0 and it is being used by JScript and Java applet programmers.

I am publicly neutral about any software produced by commercial
organisations. There have been some very good de facto standards in the
past, a lot of adequate ones, and some awful ones. History will decide.

My ideal - as stated above - is to provide an environment where the general
mass of XML users have a chance to affect the design and implementation of
XML systems. Maybe this is unrealistic? Please feel free to join in the
software effort :-)

>
>>I have looked at TreeModel in Swing and even implemented a simple JUMBO
>>display on it. I have to confess that, being a Dumb Browser Hacker, I found
>>it quite tough going. If the only interfaces to XML parsers are based on
>>this level of abstraction a lot of people will find them hard.
>
>
>My proposal was mainly for the parser writers and not the application
>writers.  Application writers will not be using XmlTreeModel but DOM
>objects.  My point was that interfaces like XmlTreeModel should be used to

*This* application writer uses NXP, Lark and AElfred because the DOM ain't
ready and because he doesn't yet understand it :-)

>write DOM framework so that the framework can support all existing and
>future XML parsers.
>
>>WE have been part way down this road before - look through XML-DEV
>>discussions 6+ months ago. I think it's essential we home in on a
>>moderately simple parser NOW - we know what we need to do - we simply need
>>to agree on the precise components and the terminology.
>
>I was not here 6+ months ago and I do not believe that just because there

The list is archived on http://www.lists.ic.ac.uk/hypermail/xml-dev. I am
not suggesting that it's all worth reading, but you might find the stuff
about API useful.

>has been previous discussions makes my proposal any less worthy.  Frankly, I

No one has doubted the worthiness of your proposal :-).  If you can find
people on XML-DEV who wish to take it up and implement it, I'd be
*delighted*. Really.
All that has happened is that three parser writers have decided to propose
a particular way forward.

>am disappointed by the fact that there was no immediate understanding of the
>advantages my proposal offers.  It is partly my fault since I am pretty bad

No, Don. It's the inertia and the time pressures. For me, it would take me
a week to understand. I don't understand the Consumers, etc. in the rest of
java very well.  I don't see where an EventConsumer is required in what I
want to do.
I understand the proposal strategically because it has the same look and
feel of  other things in Java. In a similar way I didn't understand John
Tigue's API with ParserFactorys and so on - but those who did seemed to
think they were a good way to do things. So - hope that someone less Dumb
than me picks up on your idea :-)

>at explaining things.  However, I am disturbed that, while there is a wealth
>of SGML and XML knowledge present in this mailing list, there seem to be a
>lack of object-oriented design knowledge.  I do not say this insultingly but

We all have concerns. My concern is that there aren't enough people who are
actively writing code and making it publicly available. My advice would be
to go out and write something that you think does something useful and show
people that it's a GoodThing. That's what I have done with JUMBO - very
much the Dumb persons tool (you wouldn't like to look inside JUMBO - no
Factories, no Consumers, etc.). If you or anyone would like to rewrite
JUMBO properly I'd be *delighted* :-)

>with concern.  I appologize if anyone took my opinion negatively.

One of the very positive aspects of XML/SGML is the incredible patience and
politeness of people. There are no flamewars. If people get things formally
wrong they are gently educated in a better way to do it. If their ideas are
way off beam, they often won't get a response of any kind, but if they do
it will be polite and helpful.

>
>>All I want is to get the DOCTYPE stuff from the file. AElfred now provides
>>exactly what I want - we just need to agree it.
>
>
>All one wants is not necessarily what everyone wants and will want.  Design
>of a standard API should be approached more carefully and with future in
>mind.

I don't disagree with this :-) You have your opportunity to convince
people, right here. My own suggestion is that working software is a useful
part of an argument.
>
>I am sorry if my comments upset you in anyway.  It was not my intention.

I don't get upset in virtual environments :-). [I did once :-), in a
situation so bizarre it could have come straight out of a Shakespearean
comedy. It's not polite to retell it.] Passion is important. People's
ontologies are very dear to them. Flame wars arise from colliding ontologies. 

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

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