Suggested List Protocol

Len Bullard cbullard at
Wed Feb 26 17:08:13 GMT 1997

Gavin Nicol wrote:
> >Second that.  The lack of this and a *standard* way to define
> >the parser output (eg., what esis should do but doesn't, and
> >grove/grove plans can do) have plagued SGML systems for years.
> >A proposal for this is something that can be worked on a
> >development list.
> Quite. I think we can model these objects in a number of ways
> though. I would personally like to define the objects in IDL
> *and* SGML... (for information on IDL etc. look at

So, are you saying, in terms of a grove/grove plan and the 
implementing objects/IDL?  That looks ideal.

CORBA is a nice open spec.  Last time I looked, the documents 
cost big bucks, but maybe that has changed.  My concern 
with a design like this is the usual one:  trying for 
something that works across the platforms dependably and so, 
is very useful.  What would be the alternatives to CORBA?
What would be the strengths of CORBA?

It is hard to get around the Wintel quasi-monopoly on the 
low end.  To be successful, I think one should not try.
It is best to make sure whatever implementation is sampled, 
it runs on that platform or whatever else, and duck the 
platform wars as much as possible.  It is a "goes nowhere, 
helps nothing" debate as we saw on the VRML list.

How would you view this architecturally?  How does 
the parser API work with the rest of the system?
For example, a major concern for adopting XML and 
in fact, most Internet technologies into intranet 
apps is object identification and addressing.  I 
follow the uri.bunyip debates and this is not as 
straightforward as it looks.  What does a parser 
API know or care to know about that if anything?
I don't want to conflate issues;  I want to understand 
the separation of powers so to speak, in the architecture.

I don't have enough experience as a programmer to look 
at more than the high level view of this although 
I understand most of the concepts.


xml-dev: A list for W3C XML Developers
Archived as:
To unsubscribe, send to majordomo at the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at

More information about the Xml-dev mailing list