Re: extended support for DOCDECL

                    Hello, Aleksander!

On Sat, 8 Feb 2003, Aleksander Slominski wrote:

>>I'm trying to create a DOM2 tree out of the XmlPullParser implementation.
>>For DOCDECL tag, it is kind of hard to obtain System ID and Public ID,
>>since they're either unparsed, or missing at all (if FEATURE_PROCESS_DOCDECL)
>>is set.
>hi,
>
>this is right - currently it is unspecified what is returned by
>getText() when FEATURE_XML_ROUNDTRIP is false and PROCESS_DOCDECL is
>true then what is returned is undefined (it may be even null)
>>Are there any plans adding say getSystemId() and getPublicId() methods to
>>the parser interface, so for all the nodes that have those values defined,
>>they are returned.
>i think that you are right and this information is important and needed.
>so i have now looking into adding two optional properties to allow
>reading system and public identifier and proposed that those two
>properties as required in 1.2 release of XmlPull API.

That's great. They would be reusable for for DTD entities as well,
if there are plans to spport those.

>>I understand, J2ME implementations won't probably care about DOCDECL's and
>>will only want to get raw XML, but in my case I care, since there are
>>different document types code can get, and implementation needs to know, what
>>is the document type exactly at least in order to validate, whether a
>>document is sane.
>that is right but it should be still very easy to extract this information
>even in J2ME (with minimal increase in implementation size) but i will see
>what is Stefan opinion (author of kXML2) about doing it as he has more
>experience with J2ME.

Agreed. Just pick the BNF description, and do that. However, parser
implementation just looks like a better place for that, that's all.

>>I also understand, XmlPullParser is intended for reading XML only, and
>>DTD may not really be pulled, since DTD elements are not listed as types, and
>>an implementation doesn't have a way to report them. Are there any plans
>>to support DTD tags, as an option for rich environments ?
>speaking about XPP3: absolutely yes! however this task is currently
>pre-empted by other higher priority tasks on my todo list :-)

Hmm, what is XPP3 ? :)

>however you can still use XmlPull API implementation that provides
>DOCDECL handling and validation: please give try XNI2XmlPull that is
>implementation of XmlPull API that is based on Xerces2 codebase. i
>should be updating it in very near future to support Xerces 2.3.0 as in
>this version XNI API reached stable "gold" status. currently
>as XNI2XmlPull is still in beta stage you can get it only from CVS
>location described in  http://sourceforge.net/projects/xni2xmlpull/

That is indeed an interesting project. I was looking at Xerces parser,
but 800k jar file is way beyond j2me limits, even for CDC space.

Also, validation is not what I'm look for, it will gurantee document
is all right, but still not give a clue about the DTD contents.
Just the presence of those DTD related event constants is enough. A feature
name can be defined that an implementation agrees to support, if it produces
such DTD events.

Another problem I see with pull API in general, is that if DTD is
only specified exernally, parser doesn't have a way to ask a parser
user to provide streams with the DTD, since there isn't a way for
a parser to request anything from a user. Well, may be it can throw
an exception telling that something is required, or user may specify
a map betweeen public IDs and local files (insufficient), or register
a method that is to be called upon public ID encounter.

Thanks !
    Pawel.

Bye.
--
 Pawel S. Veselov (MTS, Service Provisioning and OMA)         __ __(O) _ __
                    e-mail: [email protected]             \ V /| || '  \
                  HomePage: http://manticore.2y.net            \_/ |_||_|_|_|

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/LIgTpC/vN2EAA/xGHJAA/2U_rlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/