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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: (more) extensible SAX

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Tchistopolskii <paul@qub.com>
  • To: David Brownell <david-b@pacbell.net>,Eric van der Vlist <vdv@dyomedea.com>, xml-dev@lists.xml.org
  • Date: Tue, 05 Dec 2000 20:40:40 -0800


----- Original Message ----- 
From: David Brownell <david-b@pacbell.net>

> Which productions -- the lexical ones, or the grammatical ones?  I count
> two layers there.  (Evidently from its SGML heritage, XML doesn't have
> the cleanest of distinctions between those layers, but it exists.)  The
> SAX API is basically a grammatical layer.

Sorry for side-effect, but why do you, people, call SAX API a 'parser' or 
'grammatical layer' ?

In the existanse of yacc and lex -  I think SAX API is a lexer. 
It returns lexems. Tokens. 

For some unknown reasons this lexer has bult-in macroprocessor.

Where is 'grammatical' layer ? Wait ... Attributes? Right ? 

So the only thing which allows us to call SAX API 'parser' 
is it's ability to pack attributes into array ? Right ?

If I'm right on this, this means that to move SAX API closer 
to 'pure lexer' - attributes should fire Attribute 'event'. For example.

On another hand, SAX API could be moved into other direction. 
'more parserish'.

Then schema comes into to the game. 
We'l have a lot of fun down the road. Desiging the real XML *parser*.

Rgds.Paul.

PS. Or I don't understand something and yacc is using wrong 
terminology?  I appreciate a url to the 'correct' terminology.
 





 

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

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