Re: Contributing to kXML 1.x (multiple codepages for WBXML)
Stefan Haustein <[email protected]> Thu, 21 Nov 2002 23:28:20 +0100
| Newsgroups | gmane.comp.java.enhydra.kxml |
|---|---|
| Message-ID | <[email protected]> |
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>