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

Re: parser models

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

Arjun Ray wrote:
> 
> james anderson <james.anderson@s...> wrote:
> 
> | 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.
> 
> I'm probably misunderstanding what you're saying, but one big difference
> would seem to be that the definition of the instance is determined by the
> parser system with pull and by the application with push.

unless the parser always works with a construction context, for which application provides the initial value. in that case, the context is in the position to
instantiate model nodes. 

>                                                           If you're
> saying that access to the parser (to pull event notifications) could be
> tag-teamed - on a call stack - between instance builders and content
> handlers, I'd agree: this is just the classic recursive descent pattern.

is it? does "classic recursive descent" pass both a control instance and a model instance?

> 
> | 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.
> 
> Yes, that's why I termed the example "cheesy".  The same class need not
> implement both Element and Content interfaces. The point of the pattern is
> the ability to separate them.
> 

more general than that. the same class need not implement both the model and control interface. it applies to whatever is to be parsed, not just elements. 

...

• 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...>
  • Re: parser models
    • From: james anderson <james.anderson@s...>
  • Re: parser models
    • From: Arjun Ray <aray@n...>

• Prev by Date: Re: SVG implementations
• Next by Date: Re: parser models
• Previous by thread: Re: parser models
• Next by thread: Re: parser models
• Index(es):
  • Date
  • Thread