You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Michael Glavassevich <mr...@ca.ibm.com> on 2010/07/08 18:05:41 UTC
GSoC: How are things going?
Hi all,
It's been awhile since I've seen mailing list discussion on the GSoC
projects. Mid-term evaluations are coming up next week. I'm wondering how
things are going in general.
Ishan / Udayanga / Sanjaya,
Can each of you share a bit on your progress? Things you've accomplished?
Challenges you might be having, possibly that we could help you with?
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: GSoC: How are things going?
Posted by udayanga wickramasinghe <ma...@gmail.com>.
Hi Michael,
thnx for the feedback you have given. yes i should have put "override.xslt"
file inside Xerces sources and load it as a internal System Resource..thnx
for pointing that out. :-) .I'll do the necessary modifications...
Regards,
Udayanga
On Tue, Jul 20, 2010 at 9:34 AM, Michael Glavassevich
<mr...@ca.ibm.com>wrote:
> Hi Udayanga,
>
> I've had a chance to look at your patch. Really great work! Looking forward
> to trying this out.
>
> One comment about the JAXP transform approach ... I noticed you're reading
> the location of override.xslt from a system property which one presumably
> has to set. I think the stylesheet could be inlined in the source code or a
> file included in xercesImpl.jar. Then Xerces would always know where to load
> it from and wouldn't have to depend on any external sources to find it.
>
>
> Thanks.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> udayanga wickramasinghe <ma...@gmail.com> wrote on 07/08/2010
> 02:23:48 PM:
>
>
> > Hi Michael , Hi devs,
> > XML Schema 1.1 override implementation is progressing and i have
> > been able to implement most of the core parts needed for the
> > implementation. One major requirement for the xs:override was to
> > perform override transformations on a given <schema> document. As i
> > did discuss in this list , my initial intention was to use
> > override.xslt[1] style sheet to perform transforms on the schema
> > documents. But as it turned out ,currently there is no xslt 2.0
> > schema aware processor to do the necessary transformations as
> > specified in [1]. Therefore i had to go for a programmatic
> > transformation that does all override transformations on a given
> > schema document by passing Elements on a Schema Document and doing
> > necessary modifications to the tree itself to reflect <override>
> > semantics. However i have also implemented a JAXP compatible
> > override transformer which would enable to plug in any appropriate
> > xslt processor if need arises in the future.... :-)
> >
> > Implementation also needs to focus on evaluating dependencies during
> > an override transformation path (ie:- A-->B'-->C'-->A'-->B''....)
> > since there can be invalid documents generated (bcoz of schema
> > component collisions,etc) due to <override> semantics. This also
> > include eliminating any cycles in a dependency path. A dependency
> > analysing Implementation is in place for this , and Khaled and I are
> > currently in the stage of reviewing the implementation code and
> > testing it against different scenarios. Still work needs to be done
> > on error/collisions handling , integrating <override>
> > transformations with different stages of Xerces schema processor,etc.
> >
> > I would like to thank Khaled as well for the tremendous support and
> > feedback he has provided throughout this period . Btw I attached a
> > recently taken patch of my implementation here as well. thanks.
> >
> > Regards,
> > Udayanga
> >
> > [1]http://www.w3.org/TR/xmlschema11-1/#override-xslt
> >
>
> > On Thu, Jul 8, 2010 at 9:35 PM, Michael Glavassevich <
> mrglavas@ca.ibm.com
> > > wrote:
> > Hi all,
> >
> > It's been awhile since I've seen mailing list discussion on the GSoC
> > projects. Mid-term evaluations are coming up next week. I'm
> > wondering how things are going in general.
> >
> > Ishan / Udayanga / Sanjaya,
> >
> > Can each of you share a bit on your progress? Things you've
> > accomplished? Challenges you might be having, possibly that we could
> > help you with?
> >
> > Thanks.
> >
> > Michael Glavassevich
> > XML Parser Development
> > IBM Toronto Lab
> > E-mail: mrglavas@ca.ibm.com
> > E-mail: mrglavas@apache.org
> >
> >
> >
> > --
> > http://www.udayangawiki.blogspot.com[attachment
> > "override_new2.patch" deleted by Michael Glavassevich/Toronto/IBM]
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> > For additional commands, e-mail: j-dev-help@xerces.apache.org
>
--
http://www.udayangawiki.blogspot.com
Re: GSoC: How are things going?
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Udayanga,
I've had a chance to look at your patch. Really great work! Looking forward
to trying this out.
One comment about the JAXP transform approach ... I noticed you're reading
the location of override.xslt from a system property which one presumably
has to set. I think the stylesheet could be inlined in the source code or a
file included in xercesImpl.jar. Then Xerces would always know where to
load it from and wouldn't have to depend on any external sources to find
it.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
udayanga wickramasinghe <ma...@gmail.com> wrote on 07/08/2010
02:23:48 PM:
> Hi Michael , Hi devs,
> XML Schema 1.1 override implementation is progressing and i have
> been able to implement most of the core parts needed for the
> implementation. One major requirement for the xs:override was to
> perform override transformations on a given <schema> document. As i
> did discuss in this list , my initial intention was to use
> override.xslt[1] style sheet to perform transforms on the schema
> documents. But as it turned out ,currently there is no xslt 2.0
> schema aware processor to do the necessary transformations as
> specified in [1]. Therefore i had to go for a programmatic
> transformation that does all override transformations on a given
> schema document by passing Elements on a Schema Document and doing
> necessary modifications to the tree itself to reflect <override>
> semantics. However i have also implemented a JAXP compatible
> override transformer which would enable to plug in any appropriate
> xslt processor if need arises in the future.... :-)
>
> Implementation also needs to focus on evaluating dependencies during
> an override transformation path (ie:- A-->B'-->C'-->A'-->B''....)
> since there can be invalid documents generated (bcoz of schema
> component collisions,etc) due to <override> semantics. This also
> include eliminating any cycles in a dependency path. A dependency
> analysing Implementation is in place for this , and Khaled and I are
> currently in the stage of reviewing the implementation code and
> testing it against different scenarios. Still work needs to be done
> on error/collisions handling , integrating <override>
> transformations with different stages of Xerces schema processor,etc.
>
> I would like to thank Khaled as well for the tremendous support and
> feedback he has provided throughout this period . Btw I attached a
> recently taken patch of my implementation here as well. thanks.
>
> Regards,
> Udayanga
>
> [1]http://www.w3.org/TR/xmlschema11-1/#override-xslt
>
> On Thu, Jul 8, 2010 at 9:35 PM, Michael Glavassevich <mrglavas@ca.ibm.com
> > wrote:
> Hi all,
>
> It's been awhile since I've seen mailing list discussion on the GSoC
> projects. Mid-term evaluations are coming up next week. I'm
> wondering how things are going in general.
>
> Ishan / Udayanga / Sanjaya,
>
> Can each of you share a bit on your progress? Things you've
> accomplished? Challenges you might be having, possibly that we could
> help you with?
>
> Thanks.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
>
>
> --
> http://www.udayangawiki.blogspot.com[attachment
> "override_new2.patch" deleted by Michael Glavassevich/Toronto/IBM]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: GSoC: How are things going?
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Your welcome Sanjaya. Looking forward to seeing the xpointer() support come
together.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Sanjaya Liyanage <sa...@gmail.com> wrote on 07/09/2010 07:12:49 AM:
> Hi Michael,Hi developers,
> I am continuing the developments of the streamable subset of
> xpointer() scheme.At the moment there are five classes in my development.
> 1. SchemeHandler
> 2. XPointerSchemeHandler
> 3. NameSpaceSchemeHandler
> 4. XPointerNodeDetails
> 5. XPointerAttribDetails
> SchemeHandler class implements the XPointerPart interface and it is
> an abstract class.
> XPointerSchemeHandler class and NameSpaceSchemeHandler class extend
> the SchemeHandler.
> The common methods with similar implementation of the above child
> classes are implemented in the parent class
> The parseXPointer() and resolveXPointer() are kept as abstract
> methods in the parent class.
> XPointerNodeDetails is for keep nodes which are specified in the
> xpointer with their namespaces and their attributes.
> XPointerAttribDetails is for keep attributes which are specified in
> the xpointer with their namespaces and values.
> I have implemented the parseXPointer() for XPointerSchemeHandler and
> NameSpaceSchemeHandler.And also the scanExpr() method for tokenizing
> the xpointer and xmlns.
> At the moment I just began to implement the resolveXPointer() for
> xmlns() scheme.
> Thank you very much Michael
> for helping me and put me on the right track.
>
> Thank you.
> Sanjaya Liyanage.
>
> On Thu, Jul 8, 2010 at 2:23 PM, udayanga wickramasinghe <
> mastershield2007@gmail.com> wrote:
> Hi Michael , Hi devs,
> XML Schema 1.1 override implementation is progressing and i have
> been able to implement most of the core parts needed for the
> implementation. One major requirement for the xs:override was to
> perform override transformations on a given <schema> document. As i
> did discuss in this list , my initial intention was to use
> override.xslt[1] style sheet to perform transforms on the schema
> documents. But as it turned out ,currently there is no xslt 2.0
> schema aware processor to do the necessary transformations as
> specified in [1]. Therefore i had to go for a programmatic
> transformation that does all override transformations on a given
> schema document by passing Elements on a Schema Document and doing
> necessary modifications to the tree itself to reflect <override>
> semantics. However i have also implemented a JAXP compatible
> override transformer which would enable to plug in any appropriate
> xslt processor if need arises in the future.... :-)
>
> Implementation also needs to focus on evaluating dependencies during
> an override transformation path (ie:- A-->B'-->C'-->A'-->B''....)
> since there can be invalid documents generated (bcoz of schema
> component collisions,etc) due to <override> semantics. This also
> include eliminating any cycles in a dependency path. A dependency
> analysing Implementation is in place for this , and Khaled and I are
> currently in the stage of reviewing the implementation code and
> testing it against different scenarios. Still work needs to be done
> on error/collisions handling , integrating <override>
> transformations with different stages of Xerces schema processor,etc.
>
> I would like to thank Khaled as well for the tremendous support and
> feedback he has provided throughout this period . Btw I attached a
> recently taken patch of my implementation here as well. thanks.
>
> Regards,
> Udayanga
>
> [1]http://www.w3.org/TR/xmlschema11-1/#override-xslt
>
> On Thu, Jul 8, 2010 at 9:35 PM, Michael Glavassevich <mrglavas@ca.ibm.com
> > wrote:
> Hi all,
>
> It's been awhile since I've seen mailing list discussion on the GSoC
> projects. Mid-term evaluations are coming up next week. I'm
> wondering how things are going in general.
>
> Ishan / Udayanga / Sanjaya,
>
> Can each of you share a bit on your progress? Things you've
> accomplished? Challenges you might be having, possibly that we could
> help you with?
>
> Thanks.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
>
>
> --
> http://www.udayangawiki.blogspot.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: GSoC: How are things going?
Posted by Sanjaya Liyanage <sa...@gmail.com>.
Hi Michael,Hi developers,
I am continuing the developments of the streamable subset of
xpointer() scheme.At the moment there are five classes in my development.
1. SchemeHandler
2. XPointerSchemeHandler
3. NameSpaceSchemeHandler
4. XPointerNodeDetails
5. XPointerAttribDetails
- SchemeHandler class implements the XPointerPart interface and it is an
abstract class.
- XPointerSchemeHandler class and NameSpaceSchemeHandler class extend the
SchemeHandler.
- The common methods with similar implementation of the above child
classes are implemented in the parent class
- The parseXPointer() and resolveXPointer() are kept as abstract methods
in the parent class.
- XPointerNodeDetails is for keep nodes which are specified in the
xpointer with their namespaces and their attributes.
- XPointerAttribDetails is for keep attributes which are specified in the
xpointer with their namespaces and values.
I have implemented the parseXPointer() for XPointerSchemeHandler and
NameSpaceSchemeHandler.And also the scanExpr() method for tokenizing the
xpointer and xmlns.
At the moment I just began to implement the resolveXPointer() for xmlns()
scheme.
Thank you very much Michael for
helping me and put me on the right track.
Thank you.
Sanjaya Liyanage.
On Thu, Jul 8, 2010 at 2:23 PM, udayanga wickramasinghe <
mastershield2007@gmail.com> wrote:
> Hi Michael , Hi devs,
> XML Schema 1.1 override implementation is progressing and i have been able
> to implement most of the core parts needed for the implementation. One major
> requirement for the xs:override was to perform override transformations on
> a given <schema> document. As i did discuss in this list , my initial
> intention was to use override.xslt[1] style sheet to perform transforms on
> the schema documents. But as it turned out ,currently there is no xslt 2.0
> schema aware processor to do the necessary transformations as specified in
> [1]. Therefore i had to go for a programmatic transformation that does all
> override transformations on a given schema document by passing Elements on a
> Schema Document and doing necessary modifications to the tree itself to
> reflect <override> semantics. However i have also implemented a JAXP
> compatible override transformer which would enable to plug in any
> appropriate xslt processor if need arises in the future.... :-)
>
> Implementation also needs to focus on evaluating dependencies during an
> override transformation path (ie:- A-->B'-->C'-->A'-->B''....) since there
> can be invalid documents generated (bcoz of schema component collisions,etc)
> due to <override> semantics. This also include eliminating any cycles in a
> dependency path. A dependency analysing Implementation is in place for this
> , and Khaled and I are currently in the stage of reviewing the
> implementation code and testing it against different scenarios. Still work
> needs to be done on error/collisions handling , integrating <override>
> transformations with different stages of Xerces schema processor,etc.
>
> I would like to thank Khaled as well for the tremendous support and
> feedback he has provided throughout this period . Btw I attached a recently
> taken patch of my implementation here as well. thanks.
>
> Regards,
> Udayanga
>
> [1]http://www.w3.org/TR/xmlschema11-1/#override-xslt
>
>
> On Thu, Jul 8, 2010 at 9:35 PM, Michael Glavassevich <mr...@ca.ibm.com>wrote:
>
>> Hi all,
>>
>> It's been awhile since I've seen mailing list discussion on the GSoC
>> projects. Mid-term evaluations are coming up next week. I'm wondering how
>> things are going in general.
>>
>> Ishan / Udayanga / Sanjaya,
>>
>> Can each of you share a bit on your progress? Things you've accomplished?
>> Challenges you might be having, possibly that we could help you with?
>>
>> Thanks.
>>
>> Michael Glavassevich
>> XML Parser Development
>> IBM Toronto Lab
>> E-mail: mrglavas@ca.ibm.com
>> E-mail: mrglavas@apache.org
>>
>
>
>
> --
> http://www.udayangawiki.blogspot.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
Re: GSoC: How are things going?
Posted by udayanga wickramasinghe <ma...@gmail.com>.
Hi Michael , Hi devs,
XML Schema 1.1 override implementation is progressing and i have been able
to implement most of the core parts needed for the implementation. One major
requirement for the xs:override was to perform override transformations on
a given <schema> document. As i did discuss in this list , my initial
intention was to use override.xslt[1] style sheet to perform transforms on
the schema documents. But as it turned out ,currently there is no xslt 2.0
schema aware processor to do the necessary transformations as specified in
[1]. Therefore i had to go for a programmatic transformation that does all
override transformations on a given schema document by passing Elements on a
Schema Document and doing necessary modifications to the tree itself to
reflect <override> semantics. However i have also implemented a JAXP
compatible override transformer which would enable to plug in any
appropriate xslt processor if need arises in the future.... :-)
Implementation also needs to focus on evaluating dependencies during an
override transformation path (ie:- A-->B'-->C'-->A'-->B''....) since there
can be invalid documents generated (bcoz of schema component collisions,etc)
due to <override> semantics. This also include eliminating any cycles in a
dependency path. A dependency analysing Implementation is in place for this
, and Khaled and I are currently in the stage of reviewing the
implementation code and testing it against different scenarios. Still work
needs to be done on error/collisions handling , integrating <override>
transformations with different stages of Xerces schema processor,etc.
I would like to thank Khaled as well for the tremendous support and feedback
he has provided throughout this period . Btw I attached a recently taken
patch of my implementation here as well. thanks.
Regards,
Udayanga
[1]http://www.w3.org/TR/xmlschema11-1/#override-xslt
On Thu, Jul 8, 2010 at 9:35 PM, Michael Glavassevich <mr...@ca.ibm.com>wrote:
> Hi all,
>
> It's been awhile since I've seen mailing list discussion on the GSoC
> projects. Mid-term evaluations are coming up next week. I'm wondering how
> things are going in general.
>
> Ishan / Udayanga / Sanjaya,
>
> Can each of you share a bit on your progress? Things you've accomplished?
> Challenges you might be having, possibly that we could help you with?
>
> Thanks.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
--
http://www.udayangawiki.blogspot.com
Re: GSoC: How are things going?
Posted by Ishan Jayawardena <ud...@gmail.com>.
Hi Michael, Hi all,
Thanks for your feedback.
On 7/20/10, Michael Glavassevich <mr...@ca.ibm.com> wrote:
>
> Just curious. Are methods 1. and 2. being added to XSObject or is this a
> new interface?
>
Well, we have created two classes. One for the SCD Parser (SCDParser)
and one for the SCD resolver (SCDResolver). The methods 1 and 2 have
been added to the SCDResolver class. The SCDParser class handles all
the parsing jobs including parsing of relative SCDs and SCPs and
creating Steps from those parsed expressions.
>
> So you may have noticed we've been discussing what the minimum JDK level
> should be for the immediate future. Based on that I think we're only going
> to require JDK 1.4 for the XML Schema 1.1 implementation, which means we
> cannot use generics yet.
>
That will be OK. We will use the existing XSObjectList interface
instead of Generics until we switch to a higher JDK version. But I
prefer using Generics.
>
> Hmmm... not sure of the details, but wonder if there's an alternate
> solution where we could introduce a new interface which both XSObject and
> XSModel extend. Perhaps Sandy could comment.
>
Well, I'm not sure either. I think the option that you've suggested is
much better because still, I think there's no any efficient way to get
the current components that are linked to a given component by a given
arc and there's other SCD related stuff that can be clearly separated
from XSObject interface and made to a different unit(i.e an interface
or a class). This will be much more meaningful.
>
> Makes sense since we haven't defined these yet in the XSModel. Something to
> do later.
>
Yes.
Thanks.
--
Best Regards,
Ishan Jayawardena (ඉෂාන් ජයවර්ධන).
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: GSoC: How are things going?
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Ishan,
It sounds like things are going well. A few comments / questions below.
Ishan Jayawardena <ud...@gmail.com> wrote on 07/08/2010 02:24:46 PM:
> Hi Michael,
>
> Thanks for reminding us. Actually for the past couple of weeks I was
> writing the SCDParser.I am sorry about not sending updates
> regularly. Sandy and I talk once a week and in our call we plan work
> for the upcoming week and review the work done during that week.
> Right now, the following is the API that we suggest for SCD
>
> 1. public XSObjectList resolve(String relativeSCD) // xmlns(p=
> http://example.com/schema/po)xscd(/type::p:USAddress)
> 2. public XSObjectList resolve(String relativeSCD, XSObject current)
>
> 3. public static XSObjectList resolve(String scp, NamespaceContext
> nsContext) // /type::p:USAddress
> 4. public static XSObjectList resolve(String scp, NamespaceContext
> nsContext, XSObject current)
>
> If you have any suggestion about any of these methods, please let us
know.
Just curious. Are methods 1. and 2. being added to XSObject or is this a
new interface?
> As I have mentioned in my proposal, the project work consists of two
> main components
> 1. writing the SCD parser
> 2. writing the SCD evaulator
> So by now, I have completed 95% of the parser and now looking into
> the spec and the XSModel and other related interfaces with the help
> of Sandy, to start writing the evaulator. Actually, we started its work
today.
>
> There are couple of challenges that I came across when trying to
> write the parser and the evaluator.
> The first problem was spoken out in the list once. It is about
> whether to use Generics or not. And for now, we have decided not to
> use Generics. I would like to know your suggestions about this matter.
So you may have noticed we've been discussing what the minimum JDK level
should be for the immediate future. Based on that I think we're only going
to require JDK 1.4 for the XML Schema 1.1 implementation, which means we
cannot use generics yet.
> The next challenge is that the XSModel interface does not implement
> the XSObject interface like other interfaces that correspond to
> other schema components do. So this is going to affect the design of
> the resolve() methods and for now, we have decided to handle the
> schema component separately. In the mean time, Sandy will be looking
> into modifying XSModel interface to implement the XSObject interface
> and once it's done, we will be able to handle schema components in
> the same way as other components.
Hmmm... not sure of the details, but wonder if there's an alternate
solution where we could introduce a new interface which both XSObject and
XSModel extend. Perhaps Sandy could comment.
> In addition to that, we are unable to support the following component
types
>
> Components defined in XML schema 1.1
> 1. Type Alternative
> 2. Assertion
Makes sense since we haven't defined these yet in the XSModel. Something to
do later.
> Component types not defined yet for Xerces
> 1. Fundamental Facet
>
> We have decided to return empty parameters appropriately when we
> encounter them within the implementation.
> If you have any suggestion regarding any of these matters, or if you
> want to know about any specific details about the methods or the
> classes involved (i.e. the overall design) please let me know.
>
> Thank you very much.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: GSoC: How are things going?
Posted by Ishan Jayawardena <ud...@gmail.com>.
Hi Michael,
Thanks for reminding us. Actually for the past couple of weeks I was writing
the SCDParser.I am sorry about not sending updates regularly. Sandy and I
talk once a week and in our call we plan work for the upcoming week and
review the work done during that week.
Right now, the following is the API that we suggest for SCD
1. public XSObjectList resolve(String relativeSCD) // xmlns(p=
http://example.com/schema/po)xscd(/type::p:USAddress)
2. public XSObjectList resolve(String relativeSCD, XSObject current)
3. public static XSObjectList resolve(String scp, NamespaceContext
nsContext) // /type::p:USAddress
4. public static XSObjectList resolve(String scp, NamespaceContext
nsContext, XSObject current)
If you have any suggestion about any of these methods, please let us know.
As I have mentioned in my proposal, the project work consists of two main
components
1. writing the SCD parser
2. writing the SCD evaulator
So by now, I have completed 95% of the parser and now looking into the spec
and the XSModel and other related interfaces with the help of Sandy, to
start writing the evaulator. Actually, we started its work today.
There are couple of challenges that I came across when trying to write the
parser and the evaluator.
The first problem was spoken out in the list once. It is about whether to
use Generics or not. And for now, we have decided not to use Generics. I
would like to know your suggestions about this matter.
The next challenge is that the XSModel interface does not implement the
XSObject interface like other interfaces that correspond to other schema
components do. So this is going to affect the design of the resolve()
methods and for now, we have decided to handle the schema component
separately. In the mean time, Sandy will be looking into modifying XSModel
interface to implement the XSObject interface and once it's done, we will be
able to handle schema components in the same way as other components.
In addition to that, we are unable to support the following component types
Components defined in XML schema 1.1
1. Type Alternative
2. Assertion
Component types not defined yet for Xerces
1. Fundamental Facet
We have decided to return empty parameters appropriately when we encounter
them within the implementation.
If you have any suggestion regarding any of these matters, or if you want to
know about any specific details about the methods or the classes involved
(i.e. the overall design) please let me know.
Thank you very much.
On Thu, Jul 8, 2010 at 9:35 PM, Michael Glavassevich <mr...@ca.ibm.com>wrote:
> Hi all,
>
> It's been awhile since I've seen mailing list discussion on the GSoC
> projects. Mid-term evaluations are coming up next week. I'm wondering how
> things are going in general.
>
> Ishan / Udayanga / Sanjaya,
>
> Can each of you share a bit on your progress? Things you've accomplished?
> Challenges you might be having, possibly that we could help you with?
>
> Thanks.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
--
Best Regards,
Ishan Jayawardena (ඉෂාන් ජයවර්ධන).