Hi Hiranya, Thank you for your guidelines, I will follow them when working with the code base in the future.
On 11/20/10, Hiranya Jayathilaka <[email protected]> wrote: > 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] > > -- Best Regards, Ishan Jayawardena. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
