Sandy, Initially, the issue we had was that we did not have a means to return an XSModel(i.e the schema description schema component) as an XSObject because the resolve() method was supposed to return a list of XSObjects.
On 11/16/10, Sandy Gao <[email protected]> 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. > I am wondering if this approach addresses that issue because if we take this approach, we will have to return a list of "SchemaComponent"s. If I am wrong please tell me. That's why I proposed following method class Schema implements XSModel, XSObject { } So that we will be able to treat the "Schema" as an XSObject and an XSModel at the same time. > 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.) Are you saying that what I suggest lets users of XSModel treat it as an XSObject? ( Or it does not prevent treating XSModel as an XSObject?). I don't quite understand this. Can you please explain a bit? > 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. > +1 But still, I think the method you suggest is the much more better than mine. Can I try this out? > Thoughts from others? > > 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] >> -- Best Regards, Ishan Jayawardena. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
