Paul Sandoz wrote:
> 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.
I'd appreciate that.
>
>
>>>> 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!
I'm in the U.K. 9-11 am PT is 5-7 pm here,which is absolutely OK for me
as well.
>
>
>>> 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 :-)
OK, let's talk about it on Monday.
>
>
>>> 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.
>
I agree.
>
>>> 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.
Thank you for your proposal, which I think is perfect. I'll look into
those existing frameworks in FISE and try to figure out how to integrate
FIME to them.
Cheers,
Ias
>
> 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
>>
>