Changshin Lee wrote:
>>
>>
>> Wow!. I will check it out.
>>
>>
>>
> Please make sure that you have FIME (FI + ME -> FIME) 0.1, a workable
> version :-)
>
OK. I will look at this on Monday.
>>
>>
>>> I have a couple of items I've found during this work.
>>>
>>> 1. Two XMLChar classes
>>> There are two different XMLChar in FI source. It seems that XMLChar
>>> in fi.util is not used.
>>>
>>>
>>
>>
>> Yes. This needs to be resolved. There is one very large class copied
>> from Xerces and we should reused this the remove the other one. Both
>> should be used, one by the Encoder and the other i recall by StAX for
>> events.
>>
>> The large Xerces class should not be used for ME since it creates a very
>> large table. I wonder what ME parsers to do efficiently check unicode
>> ranges for the validation of unicode characters as specified by XML 1.x?
>>
>>
> That's a pain in the Java ME's neck.
I agree.
> As far as I'm concerned, Java ME
> Web Services (JSR 172) doesn't mention about it explicitly and I also
> didn't implemented it in Mirae, I remember.
>
When the first public review of 172 occured Elliot Rusty Harold kicked
up quite a fuss (i think rightly so) because the XML parser was not
required to support DTDs, so the JSR was changed to suport DTDs.
JSR 172 is not designed to subset XML 1.0 although SOAP 1.x essentially
does that. The XML parser was initially written to support just SOAP
messages but others wanted to use the parser in non SOAP scenarios.
I know the person who implemented the SAX RI implementation for 172 i
will ask him what he did.
>>> 3. Advice
>>> I just worked on making FI ME compilable on CLDC, and think I need to
>>> cut some weight out of it because at my first sight it looks a little
>>> bit heavy in terms of binary size and number of classes, fields, and
>>> methods. Please let me get your advice and recommendation on
>>> streamlining FI ME, particularly, considering that FI ME supports
>>> only StAX.
>>>
>>>
>>
>>
>> I agree. The conversion from strings to binary-data is not needed and
>> will be rarely used if at all (it is not used in the SE impl it is just
>> there for completeness).
>>
>> Are you also implementing the event API?
>>
>>
> No, StAX ME doesn't have the event API package as StAX 1.0 spec states.
>
Ah yes, i remember now.
>>
>>
>>
>>> I'll post more details when I complete FI 0.1.
>>>
>>>
>>
>>
>>
>> OK.
>>
>> Perhaps it would be best to have a con-call or IRC chat about all this?
>>
>>
> I prefer irc or instant messaging (I did once with Santiago). My AIM
> name is ias_and_cb_at_mac.com. I guess we have only one hour time gap :-)
>
How about we meet on Monday? I cannot recall where you are based.
Between 9am and 11am PT would be best for me but i can adjust!
>> Do you want developer/commit access to the FI workspace? It would
>> certainly be good if this was part of Java.Net, either as part of FI or
>> as a related .net project.
>>
>>
> Actually my plan is to have StAX ME and FIME in Mirae as they are main
> topics of my presentation in ApacheCon 2005 Europe.
OK.
> I think that FIME
> alone could be better if it's in Java.net, yes, I agree on your point.
>
That would be great :-)
>> I am not sure how feasible it is to share a subset of code for SE and
>> ME. Since the optimization strategies are different sharing code and
>> modifying may unduely affect one platform in unintended ways.
>>
>>
> As you might notice, FIME is quite small comparing with FI, and even it
> should become much more light after all.
Excellent.
> In order to achieve that goal,
> overall changes over FI will be required. What I've learned from the
> first step of the porting work is that what we can share in essential is
> core algorithms and processes. I'll work on figuring out how we can take
> mutual advantage.
>
Sounds good. What is important to ensure is that no performance
regressions occur. So i think we need to prototype and compare
peformance of the existing implementation and the refactored implementation.
>> If we have separate code then we need to have tests in place for
>> interoperability. We have a whole bunch of XML files. I can convert them
>> to FI using the SE serializer and use this as the baseline for tests.
>>
>>
> Interoperability is in great need as I'm demonstration a scenario that
> Mirae and JWSDP 1.6 interact over FI. We need to guarantee
> interoperability in two ways:
>
> 1. FIME -> write a FI document -> FI -> read it
> 2. FI -> write a FI document -> FIME -> read it
>
> Do you have an idea of how we can do this smoothly? Probably a testing
> framework for the interoperability is useful.
>
There are unix scripts that test round trip functionality of the parsers
and serializers. See the FastInfoset/bin directory [1]. We also have
automated round trip tests in [2]. There are a whole bunch of XML files
in [2] that exercise the parsing.
I would propose these testing stages:
1) Check for round trip conformance of the FIME parsers and serializers.
2) Check for interop of FISE and FIME.
2.1) FISE encoded documents parsed by FIME.
2.2) FIME encoded documents parsed by FISE.
Paul.
[1]
https://fi.dev.java.net/source/browse/fi/FastInfoset/bin/
[2]
https://fi.dev.java.net/source/browse/fi/RoundTripTests/
> Thank you,
>
> Ias
>
>> Paul.
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_fi.dev.java.net
> For additional commands, e-mail: dev-help_at_fi.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109