You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Ishan Jayawardena <ud...@gmail.com> on 2010/10/01 05:09:54 UTC

Re: SCP Progress

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 <mr...@ca.ibm.com> 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: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> Ishan Jayawardena <ud...@gmail.com> 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 <mu...@apache.org> wrote:
>> > On Mon, Jul 26, 2010 at 8:57 PM, Ishan Jayawardena <ud...@gmail.com>
>> > 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: j-dev-unsubscribe@xerces.apache.org
>> > For additional commands, e-mail: j-dev-help@xerces.apache.org
>> >
>> >
>>
>>
>> --
>> Best Regards,
>> Ishan Jayawardena.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> For additional commands, e-mail: j-dev-help@xerces.apache.org


-- 
Best Regards,
Ishan Jayawardena.

Re: SCP Progress

Posted by Michael Glavassevich <mr...@ca.ibm.com>.
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: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Ishan Jayawardena <ud...@gmail.com> 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 <mr...@apache.org> 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 <ud...@gmail.com> 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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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 <mr...@ca.ibm.com> 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: mrglavas@ca.ibm.com
> >> > >> > E-mail: mrglavas@apache.org
> >> > >> >
> >> > >> > Ishan Jayawardena <ud...@gmail.com> 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 <mu...@apache.org> wrote:
> >> > >> >> > On Mon, Jul 26, 2010 at 8:57 PM, Ishan Jayawardena
> >> > > <ud...@gmail.com>
> >> > >> >> > 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: j-dev-unsubscribe@xerces.apache.org
> >> > >> >> > For additional commands, e-mail:
j-dev-help@xerces.apache.org
> >> > >> >> >
> >> > >> >> >
> >> > >> >>
> >> > >> >>
> >> > >> >> --
> >> > >> >> Best Regards,
> >> > >> >> Ishan Jayawardena.
> >> > >> >>
> >> > >> >>
> >> ---------------------------------------------------------------------
> >> > >> >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> >> > >> >> For additional commands, e-mail: j-dev-help@xerces.apache.org
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Best Regards,
> >> > >> Ishan Jayawardena.
> >> > >> [attachment "patches.zip" deleted by Sandy Gao/Toronto/IBM]
> >> > >>
---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> >> > >> For additional commands, e-mail: j-dev-help@xerces.apache.org
> >> >
> >> >
> >> > --
> >> > Best Regards,
> >> > Ishan Jayawardena.
> >> >
> >> >
---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> >> > For additional commands, e-mail: j-dev-help@xerces.apache.org
> >
> > ---------------------------
> > Michael Glavassevich
> > XML Parser Development
> > IBM Toronto Lab
> > E-mail: mrglavas@ca.ibm.com
> > E-mail: mrglavas@apache.org
> >
>
>
> --
> Best Regards,
> Ishan Jayawardena.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: SCP Progress

Posted by Ishan Jayawardena <ud...@gmail.com>.
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 <hi...@gmail.com> 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 <ud...@gmail.com>
> 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 <mr...@apache.org> 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 <ud...@gmail.com> 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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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 <mr...@ca.ibm.com> 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: mrglavas@ca.ibm.com
>>>> > >> > E-mail: mrglavas@apache.org
>>>> > >> >
>>>> > >> > Ishan Jayawardena <ud...@gmail.com> 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 <mu...@apache.org> wrote:
>>>> > >> >> > On Mon, Jul 26, 2010 at 8:57 PM, Ishan Jayawardena
>>>> > > <ud...@gmail.com>
>>>> > >> >> > 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: j-dev-unsubscribe@xerces.apache.org
>>>> > >> >> > For additional commands, e-mail: j-dev-help@xerces.apache.org
>>>> > >> >> >
>>>> > >> >> >
>>>> > >> >>
>>>> > >> >>
>>>> > >> >> --
>>>> > >> >> Best Regards,
>>>> > >> >> Ishan Jayawardena.
>>>> > >> >>
>>>> > >> >>
>>>> ---------------------------------------------------------------------
>>>> > >> >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>>>> > >> >> For additional commands, e-mail: j-dev-help@xerces.apache.org
>>>> > >>
>>>> > >>
>>>> > >> --
>>>> > >> Best Regards,
>>>> > >> Ishan Jayawardena.
>>>> > >> [attachment "patches.zip" deleted by Sandy Gao/Toronto/IBM]
>>>> > >> ---------------------------------------------------------------------
>>>> > >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>>>> > >> For additional commands, e-mail: j-dev-help@xerces.apache.org
>>>> >
>>>> >
>>>> > --
>>>> > Best Regards,
>>>> > Ishan Jayawardena.
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>>>> > For additional commands, e-mail: j-dev-help@xerces.apache.org
>>>
>>> ---------------------------
>>> Michael Glavassevich
>>> XML Parser Development
>>> IBM Toronto Lab
>>> E-mail: mrglavas@ca.ibm.com
>>> E-mail: mrglavas@apache.org
>>>
>>
>>
>> --
>> Best Regards,
>> Ishan Jayawardena.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> For additional commands, e-mail: j-dev-help@xerces.apache.org
>>
>
>
>
> --
> Hiranya Jayathilaka
> Senior Software Engineer;
> WSO2 Inc.;  http://wso2.org
> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>


-- 
Best Regards,
Ishan Jayawardena.

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: SCP Progress

Posted by Hiranya Jayathilaka <hi...@gmail.com>.
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 <ud...@gmail.com> 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 <mr...@apache.org> 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 <ud...@gmail.com> 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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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 <mr...@ca.ibm.com> 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: mrglavas@ca.ibm.com
>>> > >> > E-mail: mrglavas@apache.org
>>> > >> >
>>> > >> > Ishan Jayawardena <ud...@gmail.com> 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 <mu...@apache.org> wrote:
>>> > >> >> > On Mon, Jul 26, 2010 at 8:57 PM, Ishan Jayawardena
>>> > > <ud...@gmail.com>
>>> > >> >> > 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: j-dev-unsubscribe@xerces.apache.org
>>> > >> >> > For additional commands, e-mail: j-dev-help@xerces.apache.org
>>> > >> >> >
>>> > >> >> >
>>> > >> >>
>>> > >> >>
>>> > >> >> --
>>> > >> >> Best Regards,
>>> > >> >> Ishan Jayawardena.
>>> > >> >>
>>> > >> >>
>>> ---------------------------------------------------------------------
>>> > >> >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>>> > >> >> For additional commands, e-mail: j-dev-help@xerces.apache.org
>>> > >>
>>> > >>
>>> > >> --
>>> > >> Best Regards,
>>> > >> Ishan Jayawardena.
>>> > >> [attachment "patches.zip" deleted by Sandy Gao/Toronto/IBM]
>>> > >> ---------------------------------------------------------------------
>>> > >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>>> > >> For additional commands, e-mail: j-dev-help@xerces.apache.org
>>> >
>>> >
>>> > --
>>> > Best Regards,
>>> > Ishan Jayawardena.
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>>> > For additional commands, e-mail: j-dev-help@xerces.apache.org
>>
>> ---------------------------
>> Michael Glavassevich
>> XML Parser Development
>> IBM Toronto Lab
>> E-mail: mrglavas@ca.ibm.com
>> E-mail: mrglavas@apache.org
>>
>
>
> --
> Best Regards,
> Ishan Jayawardena.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>



-- 
Hiranya Jayathilaka
Senior Software Engineer;
WSO2 Inc.;  http://wso2.org
E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: SCP Progress

Posted by Ishan Jayawardena <ud...@gmail.com>.
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 <mr...@apache.org> 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 <ud...@gmail.com> 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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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 <mr...@ca.ibm.com> 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: mrglavas@ca.ibm.com
>> > >> > E-mail: mrglavas@apache.org
>> > >> >
>> > >> > Ishan Jayawardena <ud...@gmail.com> 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 <mu...@apache.org> wrote:
>> > >> >> > On Mon, Jul 26, 2010 at 8:57 PM, Ishan Jayawardena
>> > > <ud...@gmail.com>
>> > >> >> > 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: j-dev-unsubscribe@xerces.apache.org
>> > >> >> > For additional commands, e-mail: j-dev-help@xerces.apache.org
>> > >> >> >
>> > >> >> >
>> > >> >>
>> > >> >>
>> > >> >> --
>> > >> >> Best Regards,
>> > >> >> Ishan Jayawardena.
>> > >> >>
>> > >> >>
>> ---------------------------------------------------------------------
>> > >> >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> > >> >> For additional commands, e-mail: j-dev-help@xerces.apache.org
>> > >>
>> > >>
>> > >> --
>> > >> Best Regards,
>> > >> Ishan Jayawardena.
>> > >> [attachment "patches.zip" deleted by Sandy Gao/Toronto/IBM]
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> > >> For additional commands, e-mail: j-dev-help@xerces.apache.org
>> >
>> >
>> > --
>> > Best Regards,
>> > Ishan Jayawardena.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> > For additional commands, e-mail: j-dev-help@xerces.apache.org
>
> ---------------------------
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>


-- 
Best Regards,
Ishan Jayawardena.

Re: SCP Progress

Posted by Michael Glavassevich <mr...@apache.org>.
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 <ud...@gmail.com> 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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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 <mr...@ca.ibm.com> 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: mrglavas@ca.ibm.com
> > >> > E-mail: mrglavas@apache.org
> > >> >
> > >> > Ishan Jayawardena <ud...@gmail.com> 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 <mu...@apache.org> wrote:
> > >> >> > On Mon, Jul 26, 2010 at 8:57 PM, Ishan Jayawardena
> > > <ud...@gmail.com>
> > >> >> > 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: j-dev-unsubscribe@xerces.apache.org
> > >> >> > For additional commands, e-mail: j-dev-help@xerces.apache.org
> > >> >> >
> > >> >> >
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Best Regards,
> > >> >> Ishan Jayawardena.
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> > >> >> For additional commands, e-mail: j-dev-help@xerces.apache.org
> > >>
> > >>
> > >> --
> > >> Best Regards,
> > >> Ishan Jayawardena.
> > >> [attachment "patches.zip" deleted by Sandy Gao/Toronto/IBM]
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> > >> For additional commands, e-mail: j-dev-help@xerces.apache.org
> >
> >
> > --
> > Best Regards,
> > Ishan Jayawardena.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> > For additional commands, e-mail: j-dev-help@xerces.apache.org

---------------------------
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Re: SCP Progress

Posted by Ishan Jayawardena <ud...@gmail.com>.
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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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 <mr...@ca.ibm.com> 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: mrglavas@ca.ibm.com
>> >> > E-mail: mrglavas@apache.org
>> >> >
>> >> > Ishan Jayawardena <ud...@gmail.com> 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 <mu...@apache.org> wrote:
>> >> >> > On Mon, Jul 26, 2010 at 8:57 PM, Ishan Jayawardena
>> > <ud...@gmail.com>
>> >> >> > 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: j-dev-unsubscribe@xerces.apache.org
>> >> >> > For additional commands, e-mail: j-dev-help@xerces.apache.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Best Regards,
>> >> >> Ishan Jayawardena.
>> >> >>
>> >> >>
> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> >> >> For additional commands, e-mail: j-dev-help@xerces.apache.org
>> >>
>> >>
>> >> --
>> >> Best Regards,
>> >> Ishan Jayawardena.
>> >> [attachment "patches.zip" deleted by Sandy Gao/Toronto/IBM]
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> >> For additional commands, e-mail: j-dev-help@xerces.apache.org
>>
>>
>> --
>> Best Regards,
>> Ishan Jayawardena.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> For additional commands, e-mail: j-dev-help@xerces.apache.org
>>


-- 
Best Regards,
Ishan Jayawardena.

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: SCP Progress

Posted by Sandy Gao <sa...@ca.ibm.com>.
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 <ud...@gmail.com> 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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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 <mr...@ca.ibm.com> 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: mrglavas@ca.ibm.com
> >> > E-mail: mrglavas@apache.org
> >> >
> >> > Ishan Jayawardena <ud...@gmail.com> 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 <mu...@apache.org> wrote:
> >> >> > On Mon, Jul 26, 2010 at 8:57 PM, Ishan Jayawardena
> > <ud...@gmail.com>
> >> >> > 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: j-dev-unsubscribe@xerces.apache.org
> >> >> > For additional commands, e-mail: j-dev-help@xerces.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Best Regards,
> >> >> Ishan Jayawardena.
> >> >>
> >> >>
---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> >> >> For additional commands, e-mail: j-dev-help@xerces.apache.org
> >>
> >>
> >> --
> >> Best Regards,
> >> Ishan Jayawardena.
> >> [attachment "patches.zip" deleted by Sandy Gao/Toronto/IBM]
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> >> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>
> --
> Best Regards,
> Ishan Jayawardena.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>

Re: SCP Progress

Posted by Ishan Jayawardena <ud...@gmail.com>.
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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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 <mr...@ca.ibm.com> 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: mrglavas@ca.ibm.com
>> > E-mail: mrglavas@apache.org
>> >
>> > Ishan Jayawardena <ud...@gmail.com> 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 <mu...@apache.org> wrote:
>> >> > On Mon, Jul 26, 2010 at 8:57 PM, Ishan Jayawardena
> <ud...@gmail.com>
>> >> > 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: j-dev-unsubscribe@xerces.apache.org
>> >> > For additional commands, e-mail: j-dev-help@xerces.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Best Regards,
>> >> Ishan Jayawardena.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> >> For additional commands, e-mail: j-dev-help@xerces.apache.org
>>
>>
>> --
>> Best Regards,
>> Ishan Jayawardena.
>> [attachment "patches.zip" deleted by Sandy Gao/Toronto/IBM]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> For additional commands, e-mail: j-dev-help@xerces.apache.org


-- 
Best Regards,
Ishan Jayawardena.

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: SCP Progress

Posted by Sandy Gao <sa...@ca.ibm.com>.
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 <ud...@gmail.com> 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 <mr...@ca.ibm.com> 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: mrglavas@ca.ibm.com
> > E-mail: mrglavas@apache.org
> >
> > Ishan Jayawardena <ud...@gmail.com> 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 <mu...@apache.org> wrote:
> >> > On Mon, Jul 26, 2010 at 8:57 PM, Ishan Jayawardena
<ud...@gmail.com>
> >> > 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: j-dev-unsubscribe@xerces.apache.org
> >> > For additional commands, e-mail: j-dev-help@xerces.apache.org
> >> >
> >> >
> >>
> >>
> >> --
> >> Best Regards,
> >> Ishan Jayawardena.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> >> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>
> --
> Best Regards,
> Ishan Jayawardena.
> [attachment "patches.zip" deleted by Sandy Gao/Toronto/IBM]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: SCP Progress

Posted by Mukul Gandhi <mu...@apache.org>.
On Sun, Oct 3, 2010 at 7:40 PM, Ishan Jayawardena <ud...@gmail.com> wrote:
> Mukul, this is already possible with the current implementation. If you look at
>
> SCDResolver#resolve(String relativeSCD)
> SCDResolver#resolve(String scp, NamespaceContext nsContext)

Thanks for the references. I'll look at SCD code-base and understand
the logic as I get a little time.

> Could you get the JUnit tests run?

Sorry I couldn't :( since I got tied up with few tasks, lately with
few of Xerces XML Schema 1.1 impl enhancements. But I'll try to run
the unit tests you've written ASAP, and report the results in case I
have useful findings.

> I have attached a patch which contains that JUnit test class.

Thanks for the unit test attachments. I'll try to run those tests.

PS: I think there's no need to have my name outside the mailing list
address :) It would be fine if that's included in xerces-dev list.


-- 
Regards,
Mukul Gandhi

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: SCP Progress

Posted by Ishan Jayawardena <ud...@gmail.com>.
Mukul,

> Don't want to interfere with what Sandy wishes to do with XSModel :) I
> think he is amongst the original designers of that interface, and he
> would know what's best for evolving the XSModel, and if doing any such
> thing would affect the Xerces XML Schema implementation (where it is
> most needed currently).
>

I think it's completely OK to share our ideas and come up with a
better design, and of course Sandy may also have something in his mind
about this. I will suggest my idea as soon as I can.

>>> I think ability to map a lexical SCD pattern like /xx/yy to an object
>>> path within XSModel tree is really an important use-case for SCD
>
>> What do you mean by this? Can you explain it a bit more?
>
> I meant the ability to resolve an absolute schema path (since my
> example starts with '/') expression to an XSModel instance target (i.e
> a subset of schema components). I think this is absent from current
> Xerces SCD implementation, as reflected in the commit trace you shared
> about SCD implementation recently.
>

Mukul, this is already possible with the current implementation. If you look at

SCDResolver#resolve(String relativeSCD)
SCDResolver#resolve(String scp, NamespaceContext nsContext)

methods, this(the thing you suggest) is what exactly these two methods
do. Could you get the JUnit tests run? The test includes some of the
use cases from the examples in the spec. Please let me know if you
have any problem in running/understanding them. I have attached a
patch which contains that JUnit test class.
I think this will help.
looking forward to your feedback.

Thank you.

-- 
Best Regards,
Ishan Jayawardena.

Re: SCP Progress

Posted by Mukul Gandhi <mu...@apache.org>.
On Sun, Oct 3, 2010 at 11:48 AM, Ishan Jayawardena <ud...@gmail.com> wrote:
> I think earlier, Sandy had an idea about modifying XSModel to implement the XSObject interface. But I'm not sure if he's
> working on that right now. May be he will say something about that.

Don't want to interfere with what Sandy wishes to do with XSModel :) I
think he is amongst the original designers of that interface, and he
would know what's best for evolving the XSModel, and if doing any such
thing would affect the Xerces XML Schema implementation (where it is
most needed currently).

>> I think ability to map a lexical SCD pattern like /xx/yy to an object
>> path within XSModel tree is really an important use-case for SCD

> What do you mean by this? Can you explain it a bit more?

I meant the ability to resolve an absolute schema path (since my
example starts with '/') expression to an XSModel instance target (i.e
a subset of schema components). I think this is absent from current
Xerces SCD implementation, as reflected in the commit trace you shared
about SCD implementation recently.



-- 
Regards,
Mukul Gandhi

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: SCP Progress

Posted by Ishan Jayawardena <ud...@gmail.com>.
Hi,
As I wrote earlier in this thread, I would like to suggest a new
class(Schema) to represent the schema description schema component in
the SCD implementation. It will have the following design.


public class Schema implements XSObject, XSModel {

    private XSModel fXSModel;
    private static final short NOTYPE = -1;

    public Schema(XSModel xSModel) {
        fXSModel = xSModel;
    }

    // overide XSObject interface methods
    // overide XSModel interface methods
}

then, in the SCPResolver we can create a schema component by,
Schema fSchema = new Schema(xsModel);

But even with this approach there are some problems regarding
overriding methods.
For example, when overriding the getType() method of the XSObject
interface, the schema does not have a corresponding value from the
XSConstants interface. This situation is common for all the other
XSObject methods as well. Can you suggest a solution for this?

I have attached both the implementation of the Schema class and the
modified SCDResolver class. If you have any suggestions or things to
clarify regarding them, please let me know.


On 10/3/10, Ishan Jayawardena <ud...@gmail.com> wrote:
> Hi Mukul,
> First of all, thank you for your feedback and all the suggestions.
>
> On 10/3/10, Mukul Gandhi <mu...@apache.org> wrote:
>> Hi Ishan,
>>     I'm not sure if I am the right person to comment on this (but
>> feeling to do so since other folks at Xerces developer's team seem to
>> be tied up :)
>>
>> I really wish following points to be addressed for Xerces SCD
>> implementation:
>>
>> 1. Since Xerces XSModel is not an XSObject, can't we create a SCD root
>> object on top of Xerces XSObject -- or may be an implementation above
>> XSModel (something like following):
>>
>> interface SCDModel extends XSObject {
>>    ...
>> }
>>
>> or may be SCDModel extends XSModel
>>
>> I'm not sure now, that which of above is more correct to be followed
>> for Xerces SCD implementation.
>>
>> I remember to have mentioned this a while ago on this list. I'm not
>> sure if Sandy saw any constraints to have them implemented. Or if you
>> discussed this with Sandy (perhaps you were short of time :(
>>
>
> I am also now looking into this and trying to come up with a better
> design. I will suggest a design as soon as I can. Then you can give
> your comments on it and we can then produce a much better
> implementation. I think earlier, Sandy had an idea about modifying
> XSModel to implement the XSObject interface. But I'm not sure if he's
> working on that right now. May be he will say something about that.
>
>> I think ability to map a lexical SCD pattern like /xx/yy to an object
>> path within XSModel tree is really an important use-case for SCD, and
>> must be implemented to consider an SCD implementation complete.
>>
>
> What do you mean by this? Can you explain it a bit more?
>
> I would like to share some thoughts about the current implementation,
> in general. i.e. we always needed to conform to the spec and
> implemented SCD exactly according to it even if we knew that the spec
> had errors at some points. Therefore the current implementation is
> completely spec compliant even if it doesn't do the right thing for
> some inputs. Currently, for some types of SCDs(i.e the (non
> normative)example SCDs given in the spec itself) there is a slight
> difference between the "expected results"(i.e. the results mentioned
> the spec) and the actual results. What sandy suggested as a solution
> was to document all these behaviors properly and rework our
> implementation whenever the spec fixes its bugs.
>
>> 2. I think it would be nice, if someone (perhaps you ...) can create
>> few use-cases for Xerces SCD implementation (kind of multiple
>> test-cases) and share with us. This would help us to learn about SCD
>> better, and what all things it can achieve. I think this will give
>> Xerces folks more motivation to learn about SCD (since it is a
>> relatively new language than say, XML Schema).
>>
>
> I will do that, but the results would be some what doubtful (or may
> even be incorrect) due to the current behavior of the resolver, as I
> explained earlier.
>
>>
>>  AM, Ishan Jayawardena <ud...@gmail.com> wrote:
>>> 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.
>>
>>
>>
>> --
>> Regards,
>> Mukul Gandhi
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> For additional commands, e-mail: j-dev-help@xerces.apache.org
>>
>>
>
>
> --
> Best Regards,
> Ishan Jayawardena.
>


-- 
Best Regards,
Ishan Jayawardena.

Re: SCP Progress

Posted by Ishan Jayawardena <ud...@gmail.com>.
Hi Mukul,
First of all, thank you for your feedback and all the suggestions.

On 10/3/10, Mukul Gandhi <mu...@apache.org> wrote:
> Hi Ishan,
>     I'm not sure if I am the right person to comment on this (but
> feeling to do so since other folks at Xerces developer's team seem to
> be tied up :)
>
> I really wish following points to be addressed for Xerces SCD
> implementation:
>
> 1. Since Xerces XSModel is not an XSObject, can't we create a SCD root
> object on top of Xerces XSObject -- or may be an implementation above
> XSModel (something like following):
>
> interface SCDModel extends XSObject {
>    ...
> }
>
> or may be SCDModel extends XSModel
>
> I'm not sure now, that which of above is more correct to be followed
> for Xerces SCD implementation.
>
> I remember to have mentioned this a while ago on this list. I'm not
> sure if Sandy saw any constraints to have them implemented. Or if you
> discussed this with Sandy (perhaps you were short of time :(
>

I am also now looking into this and trying to come up with a better
design. I will suggest a design as soon as I can. Then you can give
your comments on it and we can then produce a much better
implementation. I think earlier, Sandy had an idea about modifying
XSModel to implement the XSObject interface. But I'm not sure if he's
working on that right now. May be he will say something about that.

> I think ability to map a lexical SCD pattern like /xx/yy to an object
> path within XSModel tree is really an important use-case for SCD, and
> must be implemented to consider an SCD implementation complete.
>

What do you mean by this? Can you explain it a bit more?

I would like to share some thoughts about the current implementation,
in general. i.e. we always needed to conform to the spec and
implemented SCD exactly according to it even if we knew that the spec
had errors at some points. Therefore the current implementation is
completely spec compliant even if it doesn't do the right thing for
some inputs. Currently, for some types of SCDs(i.e the (non
normative)example SCDs given in the spec itself) there is a slight
difference between the "expected results"(i.e. the results mentioned
the spec) and the actual results. What sandy suggested as a solution
was to document all these behaviors properly and rework our
implementation whenever the spec fixes its bugs.

> 2. I think it would be nice, if someone (perhaps you ...) can create
> few use-cases for Xerces SCD implementation (kind of multiple
> test-cases) and share with us. This would help us to learn about SCD
> better, and what all things it can achieve. I think this will give
> Xerces folks more motivation to learn about SCD (since it is a
> relatively new language than say, XML Schema).
>

I will do that, but the results would be some what doubtful (or may
even be incorrect) due to the current behavior of the resolver, as I
explained earlier.

>
>  AM, Ishan Jayawardena <ud...@gmail.com> wrote:
>> 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.
>
>
>
> --
> Regards,
> Mukul Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>


-- 
Best Regards,
Ishan Jayawardena.

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: SCP Progress

Posted by Mukul Gandhi <mu...@apache.org>.
Hi Ishan,
    I'm not sure if I am the right person to comment on this (but
feeling to do so since other folks at Xerces developer's team seem to
be tied up :)

I really wish following points to be addressed for Xerces SCD implementation:

1. Since Xerces XSModel is not an XSObject, can't we create a SCD root
object on top of Xerces XSObject -- or may be an implementation above
XSModel (something like following):

interface SCDModel extends XSObject {
   ...
}

or may be SCDModel extends XSModel

I'm not sure now, that which of above is more correct to be followed
for Xerces SCD implementation.

I remember to have mentioned this a while ago on this list. I'm not
sure if Sandy saw any constraints to have them implemented. Or if you
discussed this with Sandy (perhaps you were short of time :(

I think ability to map a lexical SCD pattern like /xx/yy to an object
path within XSModel tree is really an important use-case for SCD, and
must be implemented to consider an SCD implementation complete.

2. I think it would be nice, if someone (perhaps you ...) can create
few use-cases for Xerces SCD implementation (kind of multiple
test-cases) and share with us. This would help us to learn about SCD
better, and what all things it can achieve. I think this will give
Xerces folks more motivation to learn about SCD (since it is a
relatively new language than say, XML Schema).


 AM, Ishan Jayawardena <ud...@gmail.com> wrote:
> 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.



-- 
Regards,
Mukul Gandhi

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org