xml-dev - RE: IDL?

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

At 07:55 26/12/97 -0500, David Megginson wrote:

[...]

>I have no intention of proposing anything that precludes a compiled
>language (without runtime type-checking), so if that's the only
>barrier, then there is no need for concern.

Good.  If I understand this, the creation of Sax-J will not only not
preclude the creation of a language-independent API, but should make that
easier.

>
>There _is_ a reason for concern, however, with the goals and scope of
>this project.  It will be (I hope) an easy task to design a simple
>API, with sample interfaces in Java, but we need to know what kind of
>an API we are designing, and why.
>
>For example, when DOM interfaces are available for NXP, Ælfred, and
>Lark as well as MSXML, Peter may not need any other common interface
>for Jumbo.  If people really want the DOM, then the parser writers
>should work on implementing whatever the current draft defines instead

("current draft" [of the DOM] I assume).

>of spending time on the simple interface.  If they still need the
>simple event-based interface, then I have to understand what they need
>it for:
>
>1) (My suggestion.)  A pre-DOM interface, defining the events returned
>   by an XML parser, and providing enough information to build a DOM
>   tree (PIs, attributes, elements, data, DOCTYPE declarations, etc.).
>
I wasn't aware that your suggestion and Tim's were sufficiently distinct -
I thought that the two of you had enough common ground this wasn't a concern.
By "pre-DOM" I assume you mean:
	- valid only until the DOM comes into effect
	- (possibly) a subset of DOM functionality.

>2) (Tim's suggestion.)  A post-DOM interface, for people who don't
>   want to learn the complexity of the DOM, and providing only the
>   minimum possible information (elements, attributes, and data).

By "post-DOM" I assume you mean "will not be onsoleted by the DOM", rather
than "cannot be put into operation until the DOM.
>
>Do we need either if these?  If so, which one do we want?

There are a number of possible axes here.  However I think it is very
important that we do not re-discuss this area *in such depth* that yet
again it runs into the sand. (I am assuming that a DOM interface is of the
order of 3-9 months away, and its finalisation date will often be
uncertain.  It is psychologically not a good idea to try to create
something specifically for this interstitial period.) So my axioms are:

	- the DOM approach is complex for webhackers to learn. Do NOT
underestimate the difficulty newcomers have in trying to interpret XML's
full power. 
	- webhackers will NOT use parts of XML. WF documents do not need DOCTYPEs,
webhackers may not understand NOTATION, PIs will be regarded as hardcoded
rituals.
	- the current crop of parsers show sufficient variation in terminology and
approach to confuse a webhacker trying to interface to XML.  
	- There will shortly (we hope) be a large number of webhackers.

Some typical uses of Sax-J will be:
	- "I've got this chunk of XML embedded in the middle of some HTML. How do
I read it?" [This is likely to have no DOCTYPE, will not use PIs or
NOTATION and will almost certainly not use entities.]
	- "I want to start learning about XML. Is there a simple program [== code]
that I can use to learn-as-I-go?"
	- "I don't understand the XML spec. Is there a simple subset of XML that I
can get started on?"

These concerns will endure after the DOM - indeed it may even highlight
them more strongly.

So I believe that there is a valid and useful role for an interface dealing
with elements, attributes and data. And that it will endure.

So - please don't regard the David/Tim axis as significant. One advantage
of limiting ourselves to E, A D is that it is more likely that we shall
agree, shall finish by Jan 12, etc.

Finally - as I said before - do not underestimate the value of producing
this interface.  David has pointed out that *he* needed clarification of
the goals. I hope that David and Tim can agree on a revised set of goals in
the next day or two and that we can go ahead on those. If you post on this
subject, please try to help us achieve something concrete; we know from
experience that it's very easy to broaden the outlook to a stage where
things become too diffuse for virtual collaboration.

I think we are nearly there...

	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)