|
RE: Contributing to kXML 1.x (multiple codepages for WBXML ): msg#00015java.enhydra.kxml
When I was investigating kXML a few months back, I noticed some problems with OPAQUE support (i never posted the fix on the mailing list, though, because I intended to make other changes too (e.g. support for multipage codebooks), but we ended up dropping the project and I haven't looked at the code since). I've attached the modified files: org.kxml.wap.WapExtensionEvent org.kxml.wap.WbxmlParser org.kxml.Attribute The fix also fixes a problem I was having with extracting data from a WBXML blob which contains embedded WBXML (i.e. a message containing another message in a tag attribute's value). Hope this helps. best, chris > -----Original Message----- > From: Stefan Haustein [mailto:haustein@xxxxxxxxxxxxxxxxxxxxxxx] > Sent: Thursday, November 21, 2002 4:28 PM > To: kxml@xxxxxxxxxxx > Subject: Re: Kxml: Contributing to kXML 1.x (multiple codepages for > WBXML) > > > 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> > > > _______________________________________________ > Kxml mailing list > Kxml@xxxxxxxxxxx > http://www.enhydra.org/mailman/listinfo.cgi/kxml >
|
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: Contributing to kXML 1.x (multiple codepages for WBXML), Stefan Haustein |
|---|---|
| Next by Date: | Question, Vaneet Sharma |
| Previous by Thread: | Contributing to kXML 1.x (multiple codepages for WBXML), Frank Schroeder |
| Next by Thread: | Question, Vaneet Sharma |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |