Lists Home |
Date Index |
- From: Len Bullard <firstname.lastname@example.org>
- To: Gavin Nicol <email@example.com>
- Date: Wed, 26 Feb 1997 10:55:53 -0600
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 www.omg.org).
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: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (email@example.com)