Hi Ishan, It sounds like things are going well. A few comments / questions below.
Ishan Jayawardena <[email protected]> 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: [email protected] E-mail: [email protected]
