Ishan, Thanks for continuing to work on the SCD support. I just committed your tests.
I see that many of your tests verify that the returned list from "resolve" is not empty. This is good. But I'm wondering whether we can improve it to - Ensure the number of items in the list matches the expected result. Some will be "1", and some may be expecting more than 1. - Ensure the right components are returned. "e.g. "/a/~0" should return the component "schema.getElementDeclaration(null, "a").getTypeDefinition()". Ideally, this should be how we verify that the SCD resolver is behaving properly. If doing this for all the tests is difficult (e.g. takes a lot of time), we can start with a number of selected tests. (I will give the "how to return the schema itself" question some thought and respond. Thanks, Sandy Gao XML Technologies, IBM Canada Editor, W3C XML Schema WG. (1-905) 413-3255 T/L 313-3255 Ishan Jayawardena <[email protected]> wrote on 2010-09-30 11:09:54 PM: > [image removed] > > Re: SCP Progress > > Ishan Jayawardena > > to: > > j-dev > > 2010-09-30 11:10 PM > > Please respond to j-dev > > Hi, > I thought of reminding you about the work I did during the summer of > code program. Sandy has already committed the SCD work to the schema > 1.1 branch[0]. Also I wrote a JUnit test for it and I have attached it > with this. If you have any concern, please let me know. Looking > forward to have any comment or suggestion. > > [0] http://svn.apache.org/viewvc/xerces/java/branches/xml-schema-1. > 1-dev/src/org/apache/xerces/impl/scd/ > > Thanks. > > On 7/27/10, Michael Glavassevich <[email protected]> wrote: > > > > At the time I was thinking something more along the lines of: > > > > public interface XSModel extends SchemaComponent {} > > public interface XSObject extends SchemaComponent {} > > > > deriving some kind of common interface which both XSModel and XSObject > > extend. > > > > Michael Glavassevich > > XML Parser Development > > IBM Toronto Lab > > E-mail: [email protected] > > E-mail: [email protected] > > > > Ishan Jayawardena <[email protected]> wrote on 07/27/2010 02:22:08 AM: > > > >> Thanks for the suggestion, Mukul. I'l look into this and discuss with > >> Sandy about this. To me, it looks like a better approach instead of > >> modifying XSModel directly to implement XSObject. I think earlier, > >> Michael had also suggested something similar to this. I'l let you know > >> the details asap. > >> Thanks. > >> > >> On 7/27/10, Mukul Gandhi <[email protected]> wrote: > >> > On Mon, Jul 26, 2010 at 8:57 PM, Ishan Jayawardena <[email protected]> > >> > wrote: > >> >> 1. the Schema Step. i.e. the SCP consisting of just '/'. [0] > >> >> According to the spec, we have to return the schema component for > >> >> '/', but since the current XSModel interface doesn't implement the > >> >> XSObject interface, we have no means to return the xsmodel as a schema > >> >> component. > >> > > >> > just curious. Can't we do something like: > >> > > >> > public interface SCDXsModel implements XSModel, XSObject { > >> > > >> > } > >> > > >> > i.e you don't use XSModel directly, but use a custom inheritance > >> > design specific to SCD implementation. Therefore for example, you > >> > would use SCDXsModel and not XSModel. > >> > > >> > I haven't looked deeply at the code-base in this regard. But you might > >> > explore along the above lines, if it helps. > >> > > >> > -- > >> > Regards, > >> > Mukul Gandhi > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > > >> > >> > >> -- > >> Best Regards, > >> Ishan Jayawardena. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > > > -- > Best Regards, > Ishan Jayawardena. > [attachment "patches.zip" deleted by Sandy Gao/Toronto/IBM] > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
