Re: Contributing to kXML 1.x (multiple codepages for WBXML)

hi stefan

I have a sample WBXML file coming from an Ericsson T68 cell phone and
altough humans are not known to be good binary data parsers, I managed
to solve the mystery (with a little help from my friend WBXML spec &
khexedit):

They do include the actual payload of SyncML (data to be synchronized)
as OPAQUE data - which in turn is again a well-formed WBXML document
(with headers etc.).

To treat opaque WBXML data, in the current code there is a method called
parseWapExtension(), which creates a new WapExtensionEvent(), which in
turn is put into the variable 'next' and as far as I understand the
parsing process, this ensures that it gets parsed as well. 

I think that in the SyncML case, it needs to be configurable, what to do
with opaque data - based on the DTD in the WBXML header in it. 

Or even better: as opaque data is highly application specific, maybe we
should define an abstract class (let's call it OpaqueParseEvent for
now), so that application programmers could extend it, let it do what
they want it to do with opaque data and finally overload the SyncML()
constructor to accept a OpaqueParseEvent as argument.

What are your thoughts about this?

Please excuse my limited knowledge of WBXML/XML (partly due to the lack
of time)...

regards
nicola

ps: do you know any good sources on the net about good OO-based parser
(lexical & semantical analysis, compliation) design? I will have to
implement a compiler which accepts a subset of Java and produces java
byte code - we just started with lexical analysis some days ago and it
would be nice to get some advice about recommended desing patterns. I
don't want to realise 2 weeks before the deadline that our design sucks.
:)

DevInf2.xml
Description: Text Data

syncmlT68.wbxml
Description: Binary data