Re: extended support for DOCDECL

                    Hello, Aleksander!

There are some comments at the end.

Regarding J2ME - well, it is true, that J2ME should keep the code
as small as possible, but unfortunately people do confuse J2ME and MIDP.

The MIDP platfrorm is extremely small, where every bit counts, and the
API set is very restricted. But J2ME also covers the PDAs, where
foundation profile (FP), personal basis profile (PBP) and personal profile (PP)
take place. Those API sets are much more wide, and capabilities of target
platforms are much more generous rather than what MIDP targets.

Those developers who want to deploy to that PP enabled platforms,
would very much like to use more enabled APIs. IMHO, overrestricting
APIs to keep them small enough for MIDP may and will make those APIs
obsolete with time, when MIDP is finally replaced with PP (when a phone
reaches the today's PDAs capabilities), or just because developers
who write for PDAs will not use them.

Well, just wanted to make sure we're speaking about the same J2ME :)

Thanks,
    Pawel.

On Wed, 12 Feb 2003, Aleksander Slominski 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.

Not really, the resolver is not my concern.

The reason for having those types, is that if parser can fire corresponding
events, I can get those events, and populate my DOM tree with corresponding
notation, entity, and entityreference nodes. Then, if there is an ECMA script
code, for example, that I execute (and this is a 3rd party code), it will
get the complete DOM tree, rather than only the document elements.


>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

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