[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: parser models

• Subject: Re: parser models
• From: james anderson <james.anderson@s...>
• Date: Tue, 24 Sep 2002 14:11:34 +0200
• Cc: xml-dev@l...
• Organization: nil
• References: <r01050300-1015-399AD282CE5611D6B76F0003937A08C2@[192.168.124.21]> <200209232145.RAA03126@m...> <skf0pugrt2v186al9126s64sdn2g062l0b@4...>
• Reply-to: james.anderson@s...

where the parser manages a construction context and offers the application control over the initial context and a mechanism to generate new contexts, a pull
parser is the same as a push parser.

the wilbur rdf parser was originally written to a sax-like parser interface. by implementing the appropriate behaviour in cl-xml's construction contexts, it was
trivial to use it - ostensibly a pull parser - to drive wilbur's rdf construction logic, that is, to turn it around from being a pull parser to being a push parser.

in the case of a pull parser, calls like currContent.newChild, below, produce instances which are eventually passed back to the application, while in a push
parser they pass control into the application. there is little difference between the two. it would even be possible to implement construction contexts which
did both.

nb. it is better for the interface and logic to distinguish between the construction context and the constructed instance and to permit the application the
opportunity to decide whether they coincide.

Arjun Ray wrote:
> 
> ...
> 
> In search of a more "natural" idiom, I've been experimenting with a pure
> push API which supports stack-based delivery of events.  It's built around
> two mutually dependent interfaces that the consumer will have to implement
> which look like this (many details omitted):
> 
>   interface Element {
>       void      gi( String name ) ; // the element type
>       AttList   attlist( ) ; // an interface to push attribute info
>       Content   content( ) ;
>   }
> 
>   interface Content {
>       Element   newChild( ) ;
>       Content   endChild( Content child ) ;
>       void      text( char[] buf, int len, int off, boolean pcData ) ;
>       void      endContent( ) ;
>   }
> 
> The parser will maintain a stack of deferred Content instances and a
> "current Content instance", tracking the open element hierarchy.  The
> normal operation goes like this
> 
>   1.  Parser has a start-tag:
>        - calls currContent.newChild() to get an Element instance (which
>          is basically a context sensitive factory-like constructor).
>        - ...
> 
>   2.  ...
> 
>   3.  ...

...

• Follow-Ups:
  • Re: parser models
    • From: Arjun Ray <aray@n...>

• References:
  • parser models
    • From: "Simon St.Laurent" <simonstl@s...>
  • Re: parser models
    • From: John Cowan <jcowan@r...>
  • Re: parser models
    • From: Arjun Ray <aray@n...>

• Prev by Date: Re: DOCTYPE declaration in the document prolog
• Next by Date: ANN: Trivial Protocol for XML parsing; (pull,push & sockets)
• Previous by thread: Re: parser models
• Next by thread: Re: parser models
• Index(es):
  • Date
  • Thread