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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] parser models

[ Lists Home | Date Index | Thread Index ]

james anderson <james.anderson@setf.de> wrote:
| Arjun Ray wrote:

|> 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. 

Right.  That's the idea in interface Element { } - the app decides what
model to build at any point.

|> 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?

Yes, they tag team (or rather, they can).  Recursive descent is designed
to mix match-token and build-model functionality, doesn't it?

|> 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. 

Agreed, I was saying the same thing but didn't express myself clearly
enough.  The negation on "both" also applied to "either".


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

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