Re: extended support for DOCDECL

Pawel S. Veselov wrote:

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

after talking with Stefan who expressed concerns about adding anything 
more _required_ to API that would result in increased size for J2ME 
implementation and me being concerned about adding too many optional 
capabilities it seems that requiring DOCDECL event to provide text of 
document type declaration is the best solution.

i will add utility method to facilitate extraction of public and system 
identifier from DOCDECL string to achieve equivalent functionality to 
getPublic/SystemIdentifier().

in case when DOCDECL text can not be obtained verbatim (for example when 
XmlPull parser implementation is working on top of DOM2, XNI pipeline or 
other kind of XML infoset in general) we will require in version 1.2.x 
of XmlPull API to create "synthetic" DOCDECL (and to inform application 
that it is "synthetic" by requiring that parser sets some feature).

>>>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.
>
even that small addition to parser API means bigger parser 
implementation code and it means bigger size in J2ME and size *really* 
matters there so the above approach to require returning text of DOCDECL 
(even when "synthetic") seems like the best solution.

>>>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 ? :)
>
this is my implementation of XmlPull API-  XPP stands for (X)ML (P)ull 
(P)arser and currently it is its third reincarnation, for more details 
please see http://www.extreme.indiana.edu/xgws/xsoap/xpp

>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 guarantee 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.
>
when i have it implemented i will post announcement so you can check if 
it solves this problem (should be pretty soon)

>Another problem I see with pull API in general, is that if DTD is
>only specified externally, 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.
>
i guess that what you hint is to have an entity resolver and this is 
certainly a needed extension and it can be easily supported by an 
optional property that could be set on parser to indicate what entity 
resolver to use (it would be optional property so if not needed it would 
not be supported for example when in J2ME environment when trying to 
save every byte of memory is important).  when i get around to update 
XNI2XmlPull will post what i think how such XmlPull entity resolver 
could look when implemented on top of XNI so we would have both optional 
property and implementation of it for validation that it is right way to 
do it.

thanks for your very valuable comments.

alek

-- 
"Mr. Pauli, we in the audience are all agreed that your theory is crazy. 
What divides us is whether it is crazy enough to be true." Niels H. D. Bohr



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