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?
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]
>
