Hi Ishan, Can you attach your patches to a new JIRA issue? Much better for tracking than posting them to the mailing list.
Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [email protected] E-mail: [email protected] Ishan Jayawardena <[email protected]> wrote on 11/16/2010 12:42:21 PM: > 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]
