Hi Ishan, As a habit always submit your patches through the JIRA. While doing so don't forget to grant permission to use your patches under the Apache license. We are not supposed to use any patches provided over other channels.
Also I think it would be easier if you can submit all your work as a single patch instead of a collection of patch files. Just go to the root of source tree and do svn diff > filename.patch Thanks, Hiranya On Tue, Nov 16, 2010 at 11:12 PM, Ishan Jayawardena <[email protected]> wrote: > Hi, > I made modifications against the xml-schema-1.1-dev branch and created > some patches for the design that Sandy proposed. Can you apply these > patches and see if it works. Looking forward to your feedback. > Thanks. > > On 11/16/10, Michael Glavassevich <[email protected]> wrote: >> On Tue, 16 Nov 2010, Sandy Gao wrote: >> >>> Ishan, >>> >>> Sorry for taking this long to respond. I think I lean toward what Michael >>> suggested earlier: >>> >>> > public interface XSModel extends SchemaComponent {} >>> > public interface XSObject extends SchemaComponent {} >>> > >>> > deriving some kind of common interface which both XSModel and XSObject >>> extend. >>> >>> Details: we need a return type from resolveSCD() methods that can be both >>> a >>> normal schema component (the current XSObject) and the schema description >>> component (the current XSModel). 3 possibilities: >>> >>> 1. Return XSModel and make normal components implement XSModel. >>> Mechanically >>> possible, but obviously a bad idea. >>> 2. Return XSObject and make the schema description component implement >>> XSObject. This has compatibility concerns. XSModel interface users >>> wouldn't >>> be expecting a kind of XSObject that's "the schema". (What Ishan >>> proposed.) >>> 3. Introduce a new interface and make that the common base for XSModel and >>> XSObject. (What Michael proposed.) >>> >>> In an ideal world, #2 is preferable, because XSObject was meant to >>> represent >>> schema components, and "the schema", per the spec, is a kind of schema >>> component. But introducing a new SchemaComponent has a very low cost, >>> which >>> may not be worth saving if there's a risk of breaking existing >>> applications. >>> >>> The new interface can be empty (i.e. no methods). Users have to do >>> instanceof checks to cast it to XSModel or XSObject. Another design is to >>> have a getType() method which returns the same values as XSObject for >>> normal >>> components, and return a new constant for the schema. I think I like the >>> latter design, where people don't have to do instanceof to cast to >>> XSObject, >>> then getType(), then another cast. >>> >>> Thoughts from others? >> >> Sounds good to me. Just need to make sure we pick a constant value which >> won't conflict with ones we'll be adding for new XML Schema 1.1 compoments >> and possibly other future editions of XML Schema. >> >>> 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-10-18 12:55:52 PM: >>> >>> > [image removed] >>> > >>> > Re: SCP Progress >>> > >>> > Ishan Jayawardena >>> > >>> > to: >>> > >>> > j-dev >>> > >>> > 2010-10-18 12:56 PM >>> > >>> > Please respond to j-dev >>> > >>> > Hi Sandy, >>> > Thanks for your suggestions. I will modify the tests as you have >>> > shown. And, I'm looking forward to your solution for the "how to >>> > return the schema itself" problem. I hope you will also look into what >>> > I have suggested and give me feedback about it. >>> > thank you. >>> > >>> > On 10/18/10, Sandy Gao <[email protected]> wrote: >>> > > >>> > > 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] >>> > >>> > >>> > -- >>> > Best Regards, >>> > Ishan Jayawardena. >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: [email protected] >>> > For additional commands, e-mail: [email protected] >> >> --------------------------- >> Michael Glavassevich >> XML Parser Development >> IBM Toronto Lab >> E-mail: [email protected] >> E-mail: [email protected] >> > > > -- > Best Regards, > Ishan Jayawardena. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
