Re: asymmetry between serialzier and parser inwritingXMLDecl

Stefan Haustein wrote:

> > i agree with you. however we want to keep backward compatibility for time
> > being and then have 2.x version that will fix all problems that were identified.
> >
> > so i would think about it as a gradual improvement - the other possibility
> > introducing new event will break compatibility and that is what we really
> > want to avoid. anyway this affects only nextToken() method and only
> > for PROCESSING_INSTRUCTION event and i think in typical
> > 80/20 cases next() should be used.
>
> .... on the other hand, something like the isWhitespace hack would
> create legacy for new versions, and the XML spec clearly states that the
> XMLDecl must not be reported as Processing instruction....
>
> What about reporting the contents of the XMLDecl with START_DOCUMENT,
> before the first "real" event? It must be read anyway to determine
> the encoding before starting "real" parsing???

OK. this is more elegant approach. let do it this way:
* XMLDecl is not reported as PI
* after next() or nextToken() is called user application can obtain
XML version, standalone and encoding from XML declaration
in following ways:
 #  version: getProperty(" http://xmlpull.org/v1/doc/properties.html#xmldecl-version")
        returns String ("1.0") or null if XMLDecl was not read
 # standalone: getProperty(" http://xmlpull.org/v1/doc/features.html#xmldecl-standalone")
        returns Boolean: null if there was no standalone declaration
          Boolean(true) if standalon="yes" and Boolean(false) when standalone="no"
 # encoding: obtained from getInputEncoding()
        null if stream had unknown encoding (not set in setInputStream)
            and it was not declared in XMLDecl

how does it sound?

thanks,

alek