OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Simple approaches to XML implementation

[ Lists Home | Date Index | Thread Index ]
  • From: dgd@cs.bu.edu (David Durand)
  • To: xml-dev@ic.ac.uk
  • Date: Tue, 4 Mar 1997 11:34:14 -0500

At 9:55 AM +0000 3/4/97, Richard Light wrote:
>I think we need both.  Surely the API is the set of commands, switches,
>etc. which the application can use to control the behaviour of the XML
>processor and issue requests to it, while the "ESIS" is the well-
>understood format in which the XML processor serves up the requested
>results to the application?

ESIS and the text format that sgmls (and now SP) server up are different
things. The ESIS is an informal, non-normative definition of information
that an SGML application can see. The text format is one way to transmit
that information.

I am with the rest on requiring the potential for XML->XML transformation,
One reason that I pressed to have no insignificant whitespace -- because
it's only parts of the document that you can't see that can bite you.

Personally, I think we need an API with more power than ESIS, and
secondarily should strongly consider a tree-style representation that can
be optionally produced.

>Is it fair to say that the XML API is functionally equivalent to the
>command line arguments in NSGMLS, while the "XML ESIS" is (more
>obviously) equivalent to the ESIS output by NSGMLS?  That's how I tend
>to see it.

I think that the API includes 1 call for each kind of information that can
pass between the parser and the application, and _also_ an interface for
setting options.

>The advantage of an API over an NSGMLS-style command line is that you
>can have any number of bites at the cherry, retrieving relevant bits of
>the XML document each time.

This is the advantage of a parse tree-style representation -- But is likely
to be too slow for simple callbacks -- re-parsing documents moves to much
data to be attractive unless you're way memory limited.

It's actually a good argument for a way to request that a stored tree be
traversed to produce callbacks just as if a parse were being created.

>  For example, a browsing app might start by
>requesting the only element structure for the whole document (to fill an
>'outline' window), then go back and ask for content for the first few
>elements until it had enough to fill a 'data window'.

   -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________



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





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS