Simple approaches to XML implementation

[Peter Murray-Rust]

In message <3.0.32.19970301162825.006900ac at pop.intergate.bc.ca> Tim Bray writes:
[...]
> 
> Whereas I agree with the rest of Francois' contribution, this paragraph
> is not quite right.  If you change "ESIS event stream" to "Instance
> character stream", then it would be more correct.  But in fact the
> SGML->SGML declaration was not one of our goals; for example, the 

I hope I haven't muddied the waters here - SGML->SGML was not my intention
either.  The (possibly fuzzy) idea was that I (and probably others) are
familiar with ESIS because they use sgmls and 'could this help us in our
search for the ideas that go into the API'.  IOW 'could we throw out things
that didn't appear in ESIS?'.  Don't worry if it doesn't go anywhere.

> processor is not required to tell the app about [at least] comments
> and <![CDATA[ sections.  The XML spec says *nothing* about the ESIS, 
> merely, in a very abstract way, what the processor has to give the 
               ^^^^^^^^^^^^^
> application.

Fully agreed.  I am probably showing my usual impatience in trying to
resolve the 'abstract' to concrete.  From a practical point of view if
those people who have written parsers put their heads together and came
up with a suggested API, I would look at it extremely seriously and
positively.  

> 
> If either of these problems (the impossibility of SGML->SGML or the
> absence of an ESIS equivalent) is a big huge flaw in XML, there's still
> time to fix it.  The SGML->SGML problem is probably a job for the
> XML WG.  The ESIS issue is perhaps a job for this list.  I personally
> think an API is better than an ESIS [even if the ESIS were properly
> defined] anyhow.

Absolutely.  From my point of view what Lark provides as an API does what I 
want at the moment.  Maybe there are things that it doesn't do that it could 
or should, but *I don't know about them* :-).  Being a concrete person I 
understand those 'things' that go into and come out of current programs rather
than more abstract and perhaps more powerful synoptic views.

I talked last week with an important person/organisation in chemical 
informatics who is very excited about XML.  Their main worry was that it 
would become too complicated.  I share this concern, though I think it's
also important to make sure that we don't unnecessarily limit the power of
the language.  However there is no reason why we shouldn't initially limit 
the power of the API if it makes sense.  For example [as Tim says] I can do 
without the comments and CDATA.  

We've had a week to explore the boundaries of the API.  The spectrum covers 
the use of groves and 10179 (which a lot of us don't understand) to a
smaller set of more 'concrete' things which we are more at home with.  If
we take the more abstract approach it's going to take time and faith to
come up with an API.  It's probably the 'right' way, and I hope that some
members of this list are trying to systematise their ideas and a way forward.
I also understand and support the IDL approach if it really will produce
Java, C++, etc APIs automatiicaly.  *The result of this automatic
conversion must, however, be understandable by humans*.

Being a hacker, I like to do things quickly and suggest that we try to
gather together a 'concrete' API that could be used very shortly.  I would
be happy to take NXP and Lark as the starting points and say that they 
represent the current functionality that I require.  Can they converge to
a common name space?  Example: some people on this list use 'Element' where 
others use 'Node' - it's agreement at this level that I need.  Similarly I need
to know what classes a DTD might supply (is it ElementType or GI, or are
they all bundled under Element?).  And can we agree on what the totality
of the information *defined in PhaseI* is?

We don't lose anything by getting this off the ground quickly.  It exercises
the language, helps us locate resources and clarifies our thoughts.  A 
first-generation set of tools will impress the world and maybe might be 
extended into more powerful systems.  It also helps to build up a core
of documents that act as examples.

	P.

-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)