RE: [Sync4j-users] WSP Binding Status?

[Darryl C. <Dar...@op...>]

Comments embedded.

I have also dropped Jeff from the distribution, since I keep getting spam
notice bounces from him (he must not care for Openwave :-) ).

dgc

-------------
The item I note is in the JavaDocs:
-------------
public class WbxmlParser
extends AbstractXmlParser

Still Todo:

implement Processing Instructions
implement support for more than one codepages <===
-------------
I've seen this restriction in almost all WBXML parsers.  Since few protocols
use multiple code pages, very few parsers support them.

dgc

-----Original Message-----
From: Nicola Fankhauser [mailto:ni...@lu...]
Sent: Friday, August 30, 2002 1:10 PM
To: dar...@op...
Cc: Johnson, Jeff; syn...@li...
Subject: RE: [Sync4j-users] WSP Binding Status?


hi darryl

I've spent about 2 hours getting all the bits and pieces from various
documents of different projects and specifications - I hope it is a step
forward towards WAP support for sync4j.

altough I hope I have no really nasty bugs in my rather lengthy email,
critics & correction are always welcome!

On Fri, 2002-08-30 at 17:33, Darryl Champagne wrote:
> I don't see kXML as being a WBXML parser, just an XML parser.  The two are
> moderately different.  Also, while there are some WBXML parsers available,
> the last time I checked none of them supported multiple code spaces (or
was
> it multiple code pages?), both of which SyncML uses.

kXML v1.x does indeed support WBXML (as stated in [8]) - while version 2
does not (first paragraph in [9]).

I google'd around for WBXML & Java and found an example where kXML was
used to transform WBXML to XML and the other way 'round [1]. a small
Java class doing this can be found at [2].

the WBXML specification [4] says that "A binary XML document must
include a string table immediately after the public identifier." and:
"Various tokens encode references to the contents of the string table."
[6] - so much for the concern that those code pages would have to be fed
to the WBXML parser.


<dgc> This misses one issue - that default strings are specified in the
DTD/Public Identifier description, not the string table.  The C Toolkit,
available at Sourceforge, has to have all the SyncML specific identifiers
embedded in it.  That doesn't mean its difficult, but there is more than the
string table involved, and you have to switch pages (and spaces).  In
reality, when syncing with devices, most implementations have an empty
string table - they want the minimum bytes for the minimum processing, and
they aren't going to try to extract any common strings beyond the defaults.


regarding your concern of multiple code spaces:
"This version of the SyncML representation protocol specification maps
all the SyncML related DTDs into a single WBXML code space." [3]

this single code space divides into two code _pages_:

1. SyncML
2. MetInf

in a WBXML stream, a SWITCH_PAGE token can switch the current page.

<dgc> Unfortunately, the representation protocol is not the entirety of
SyncML.  The Device Info DTD/Doc is in its own code space, so you have to
deal with both, and as per the JavaDocs, multiple code pages are not yet
supported.
"This version of the DevInf DTD specification is associated with the WBXML
code space FD2 and the formal public identifier -//SYNCML//DTD DevInf
1.1//EN."


apart from these website tutorials, I think that parsing a WBXML stream
to produce plain XML should not be _that_ difficult, if we fail to find
an existing parser capable of transforming SyncML WBXML. given those
code-pages (which are delivered in the WBXML stream like specified in
[6]), it would have to get the first XML tag, look it up in the string
table, write out the full XML tag, get the next byte etc.
but this should only be necessary in the last resort.


<dgc> I think that is a loaded question - after all, if it's that easy, how
much value would kXML be for you in that case :-).  Anyhow, presumably you
can just enhance kXML v1 to support multiple code spaces, or add it to kXML
v2, (or port the C toolkit to java) but I leave that as an exercise for the
reader.....


> How certain are you of your support for WBXML?

quite sure actually - it's a part of my project at the university of
fribourg. :)

<dgc> - Good.  Glad to see the interest!  BTW: There is also the SyncML
Group on Yahoo, or questions can be sent to sup...@sy...
(although it's my turn to answer those, so the answers won't change...)


feedback is welcome!


<dgc> Hope this helps


regards
nicola

[1]: http://www.devx.com/xml/articles/bs120101/Part2/bs120101p2-1.asp
[2]: http://www.devx.com/xml/articles/bs120101/Part2/listing3.asp

[3]: SyncML representation protocol v1.1, chp. 8.1, p. 38
[7]: SyncML meta information DTD v1.1, chp. 7, p. 19

[4]: WBXML encoding specification, http://www.w3.org/TR/wbxml/
[5]: Token Structure, http://www.w3.org/TR/wbxml/#_Toc443384902
[6]: String Table, http://www.w3.org/TR/wbxml/#_Toc443384901

[8]: kXML v1.x, http://kxml.enhydra.org/project/aboutProject/index.html
[9]: kXML v2.x, http://www.kxml.org/