Hi Nicola,
to my understanding, when the opaque event is reached,
the application can retreive the byte array by casting
getContent to byte[]. This byte array can be used to
create a ByteArrayInputStream, which can be fed to a
new parser constructor. Wouldn't that be sufficient?
Concerning parsing Java code: When I started
to implement an OQL parser, I asked a friend
who had already implemented a "compiler compiler" which
flavour of lex/yacc for Java I should use.
He told me that Nicolas Wirth had said that
the best way to parse EBNF grammers is to build
a Pascal program, where each EBNF rule is
handled by a corresponding procedure. This is
what I did for the OQL parser, and also for
a OCL parser, except that I used Java instead
of PASCAL... :-) I am quite happy with this
approach. No need to learn another painful
tool configuration syntax for JavaCC or
something similar....
For parsing Java code, you may be able to
use the StreamTokenizer in java.io, or something
on top of it, I am not sure if a lookahead of
one is sufficient for the java syntax.
Of course, you do not need lots of objects, but
the experience with kXML 1 has told me that
sometimes it does not make much sense to force
an OO-design where the advantages are limited....
Best,
Stefam
Nicola Fankhauser wrote:
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.
:)
------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<SyncML xmlns='SYNCML:SYNCML1.0'>
<SyncHdr>
<VerDTD>
<![CDATA[1.0]]>
</VerDTD>
<VerProto>
<![CDATA[SyncML/1.0]]>
</VerProto>
<SessionID>
<![CDATA[3]]>
</SessionID>
<MsgID>
<![CDATA[1]]>
</MsgID>
<Target>
<LocURI>
<![CDATA[http://10.95.12.202:80]]>
</LocURI>
</Target>
<Source>
<LocURI>
<![CDATA[350316710342383]]>
</LocURI>
</Source>
<Cred>
<Meta>
<Format xmlns='syncml:metinf'>
<![CDATA[b64]]>
</Format>
<Type xmlns='syncml:metinf'>
<![CDATA[syncml:auth-basic]]>
</Type>
</Meta>
<Data>
<![CDATA[dGVzdDp0ZXN0]]>
</Data>
</Cred>
<Meta>
<MaxMsgSize xmlns='syncml:metinf'>
<![CDATA[2700]]>
</MaxMsgSize>
</Meta>
</SyncHdr>
<SyncBody>
<Put>
<CmdID>
<![CDATA[1]]>
</CmdID>
<Meta>
<Type xmlns='syncml:metinf'>
<![CDATA[application/vnd.syncml-devinf+wbxml]]>
</Type>
</Meta>
<Item>
<Source>
<LocURI>
<![CDATA[./devinf10]]>
</LocURI>
</Source>
<Data>
<DevInf xmlns='syncml:devinf'>
<VerDTD>1.0</VerDTD>
<Man>Ericsson</Man>
<SwV>R1A</SwV>
<HwV>R1A</HwV>
<DevID>350316710342383</DevID>
<DevTyp>phone</DevTyp>
<DataStore>
<SourceRef>EriPBDB</SourceRef>
<MaxGUIDSize>40</MaxGUIDSize>
<Rx-Pref>
<CTType>text/x-vcard</CTType>
<VerCT>2.1</VerCT>
</Rx-Pref>
<Rx>
<CTType>text/vcard</CTType>
<VerCT>3.0</VerCT>
</Rx>
<Tx-Pref>
<CTType>text/x-vcard</CTType>
<VerCT>2.1</VerCT>
</Tx-Pref>
<DSMem>
<MaxID>510</MaxID>
</DSMem>
<SyncCap>
<SyncType>1</SyncType>
<SyncType>2</SyncType>
</SyncCap>
</DataStore>
<DataStore>
<SourceRef>EriCalDB</SourceRef>
<MaxGUIDSize>40</MaxGUIDSize>
<Rx-Pref>
<CTType>text/x-vcalendar</CTType>
<VerCT>1.0</VerCT>
</Rx-Pref>
<Tx-Pref>
<CTType>text/x-vcalendar</CTType>
<VerCT>1.0</VerCT>
</Tx-Pref>
<DSMem>
<MaxID>300</MaxID>
</DSMem>
<SyncCap>
<SyncType>1</SyncType>
<SyncType>2</SyncType>
</SyncCap>
</DataStore>
<CTCap>
<CTType>text/x-vcard</CTType>
<PropName>BEGIN</PropName>
<ValEnum>VCARD</ValEnum>
<PropName>VERSION</PropName>
<ValEnum>2.1</ValEnum>
<PropName>N</PropName>
<PropName>FN</PropName>
<PropName>TITLE</PropName>
<PropName>ORG</PropName>
<PropName>TEL</PropName>
<ParamName>WORK</ParamName>
<ParamName>FAX</ParamName>
<ParamName>CELL</ParamName>
<ParamName>HOME</ParamName>
<PropName>EMAIL</PropName>
<ParamName>INTERNET</ParamName>
<PropName>END</PropName>
<ValEnum>VCARD</ValEnum>
<CTType>text/vcard</CTType>
<PropName>BEGIN</PropName>
<ValEnum>VCARD</ValEnum>
<PropName>VERSION</PropName>
<ValEnum>3.0</ValEnum>
<PropName>N</PropName>
<PropName>FN</PropName>
<PropName>TITLE</PropName>
<PropName>ORG</PropName>
<PropName>TEL</PropName>
<ParamName>WORK</ParamName>
<ParamName>FAX</ParamName>
<ParamName>CELL</ParamName>
<ParamName>HOME</ParamName>
<PropName>EMAIL</PropName>
<ParamName>INTERNET</ParamName>
<PropName>END</PropName>
<ValEnum>VCARD</ValEnum>
<CTType>text/x-vcalendar</CTType>
<PropName>BEGIN</PropName>
<ValEnum>VCALENDAR</ValEnum>
<ValEnum>VEVENT</ValEnum>
<PropName>VERSION</PropName>
<ValEnum>1.0</ValEnum>
<PropName>SUMMARY</PropName>
<PropName>LOCATION</PropName>
<PropName>DESCRIPTION</PropName>
<PropName>DTSTART</PropName>
<PropName>DTEND</PropName>
<PropName>AALARM</PropName>
<PropName>CATEGORIES</PropName>
<PropName>CLASS</PropName>
<ValEnum>PUBLIC</ValEnum>
<ValEnum>PRIVATE</ValEnum>
<PropName>END</PropName>
<ValEnum>VCALENDAR</ValEnum>
<ValEnum>VEVENT</ValEnum>
</CTCap>
</DevInf>
</Data>
</Item>
</Put>
<Alert>
<CmdID>
<![CDATA[2]]>
</CmdID>
<Cred>
<Meta>
<Format xmlns='syncml:metinf'>
<![CDATA[b64]]>
</Format>
<Type xmlns='syncml:metinf'>
<![CDATA[syncml:auth-basic]]>
</Type>
</Meta>
<Data>
<![CDATA[dGVzdDp0ZXN0]]>
</Data>
</Cred>
<Data>
<![CDATA[201]]>
</Data>
<Item>
<Target>
<LocURI>
<![CDATA[calendar]]>
</LocURI>
</Target>
<Source>
<LocURI>
<![CDATA[EriCalDB]]>
</LocURI>
</Source>
<Meta>
<Anchor xmlns='syncml:metinf'>
<Last>
<![CDATA[8]]>
</Last>
<Next>
<![CDATA[8]]>
</Next>
</Anchor>
</Meta>
</Item>
</Alert>
<Alert>
<CmdID>
<![CDATA[3]]>
</CmdID>
<Cred>
<Meta>
<Format xmlns='syncml:metinf'>
<![CDATA[b64]]>
</Format>
<Type xmlns='syncml:metinf'>
<![CDATA[syncml:auth-basic]]>
</Type>
</Meta>
<Data>
<![CDATA[dGVzdDp0ZXN0]]>
</Data>
</Cred>
<Data>
<![CDATA[201]]>
</Data>
<Item>
<Target>
<LocURI>
<![CDATA[contact]]>
</LocURI>
</Target>
<Source>
<LocURI>
<![CDATA[EriPBDB]]>
</LocURI>
</Source>
<Meta>
<Anchor xmlns='syncml:metinf'>
<Last>
<![CDATA[587]]>
</Last>
<Next>
<![CDATA[587]]>
</Next>
</Anchor>
</Meta>
</Item>
</Alert>
<Final/>
</SyncBody>
</SyncML>
