You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Ajith Ranabahu <aj...@gmail.com> on 2007/10/29 21:03:09 UTC
[XmlSchema] [Vote] Time for a release - take 2
Hi all,
As per the comments on RC-1 I have done the following changes
1. Added two new methods
public XmlSchemaElement getElementByName(QName name, boolean deep)
public XmlSchemaType getTypeByName(QName name, boolean deep)
These two methods were added to circumvent the issue of deep search
and also not to break the existing code. The older methods however are
deprecated. This seemed to be the path of least resistance but
suggestions are welcome :)
2. The recursion issues are solved
3. The encoding problem is solved
Please test and lets us know of any concerns. The RC-2 artifacts are hosted at
http://people.apache.org/~ajith/xmlschema/
Thanks
--
Ajith Ranabahu
Reading, after a certain age, diverts the mind too much from its
creative pursuits. Any man who reads too much and uses his own brain
too little falls into lazy habits of thinking - Albert Einstein
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
RE: [XmlSchema] [Vote] Time for a release - take 2
Posted by Benson Margulies <bi...@basistech.com>.
I can answer the 'why lookup by name' issue. When constructing schema
via API, rather than by having parsed XML, you have to lookup by name to
get the references to store in the first place.
> -----Original Message-----
> From: Glen Daniels [mailto:glen@thoughtcraft.com]
> Sent: Wednesday, October 31, 2007 8:19 AM
> To: commons-dev@ws.apache.org
> Subject: Re: [XmlSchema] [Vote] Time for a release - take 2
>
> Hi Amila:
>
> Amila Suriarachchi wrote:
> > On 10/30/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> >> So, what I'd like to do is:
> >>
> >> * (best solution) Fix the problem with the API, and don't bother
> >> providing an option for "local" searches... why would you want/need
> such
> >> a thing? (if someone can provide a solid use-case I'm flexible on
this)
> >> Fix ADB to use the new code.
> >
> > I am agree with your argument about the method signature. And also
if I
> am
> > extending it
> > ByName part can also omited since there is nothing other than the
name
> which
> > can uniquely identify the Element or type.
>
> +1, you are totally right, and if I was building from scratch now I'd
> just call the methods getElement()/getType(). But since we already
have
> the API, I'm not sure we should change the name just for that. :)
>
> > Lets take this senario to explain why ADB needs the parent schema.
> > Lets say we have three elements
> > E1(S1) refers to E2(S2) (in different schema)
> > E2(S2) refers to E3(S3) (in different schema)
> >
> > What currently ADB does is it
> > first find the schema of the E2 (i.e. S2) starting with the
> > S1. (since it should be possible to find it serching through imports
and
> > includes starting from S1)
>
> Well, hang on a sec. Can you explain to me exactly what it's doing
here
> (or point me at the code in question)? I would think you'd read in
the
> schema and then end up walking the elements inside an
> XmlSchemaComplexType - which typically means using getItems() on the
> contained sequence. To be clear, I'm imagining this:
>
> <schema targetNamespace="ns1">
> <element name="E1">
> <complexType>
> <sequence>
> <element ref="ns2:E2"/>
> </sequence>
> </complexType>
> </element>
> </schema>
>
> So my question here is why do you need the actual XmlSchema object at
> all for S2? Don't you just end up with an XmlSchemaElement for E2
when
> you're walking the structure of E1?
>
> What I'm really asking is why do you need to look anything (from a
> foreign namespace) up by name, when the object model lets you just
walk
> the objects directly?
>
> > So you can argue that why E3 can not be found starting with S1 as
well?
> yes
> > this is correct, the only thing it is inefficient since we always
have
> to
> > start search from the bottom.
> > therefore I think it is nice to have getElementByName(String) method
as
> > well.
>
> +1, seems reasonable.
>
> Thanks,
> --Glen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
RE: [XmlSchema] [Vote] Time for a release - take 2
Posted by Benson Margulies <bi...@basistech.com>.
How would getRefElement know which schema collection to look up in?
> -----Original Message-----
> From: Glen Daniels [mailto:glen@thoughtcraft.com]
> Sent: Friday, November 02, 2007 11:45 AM
> To: commons-dev@ws.apache.org
> Subject: Re: [XmlSchema] [Vote] Time for a release - take 2
>
> Hi Amila:
>
> Amila Suriarachchi wrote:
> >> What I'm really asking is why do you need to look anything (from a
> >> foreign namespace) up by name, when the object model lets you just
walk
> >> the objects directly?
> >
> > here the problem is it does not allow. if you go and see the
> > XmlSchemaElement class only method
> > getRefName() is available. it does not have a method to get the
> referenced
> > Element.
>
> Well, should we add that ability then?
>
> XmlSchemaElement realElement = element.getRefElement();
>
> > The above senario (which I mentioned in earlier mail) is appliced
when
> > getting
> > 1. Elements
> > 2, Named types
> > 3. Attributes
> > 4 Attribute Groups
> > 5. Goups
>
> OK, so what do people think of the suggestion that we fix the buggy
> method and perhaps add a new getElementByName(String) to get local
> elements?
>
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
RE: [XmlSchema] [Vote] Time for a release - take 2
Posted by Benson Margulies <bi...@basistech.com>.
I'm really hoping that someone will look at the patch I posted for 272.
> -----Original Message-----
> From: Ajith Ranabahu [mailto:ajith.ranabahu@gmail.com]
> Sent: Thursday, November 29, 2007 12:08 PM
> To: commons-dev@ws.apache.org
> Subject: Re: [XmlSchema] [Vote] Time for a release - take 2
>
> Hi all,
> I'll be doing the changes to both the trunk and the branch. I
> suppose everybody agrees to the list I've posted ?
>
> From the list of Jiras we have eight (8) unresolved issues. I
> estimate that these will take about two days for me to
> tackle. Hence the release candidate can be expected around
> the weekend.
>
> Ajith
>
> On Nov 28, 2007 11:42 PM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> > hi ajith,
> > have you done these changes to the trunk.
> >
> > Amila.
> >
> >
> > On Nov 6, 2007 4:29 AM, Ajith Ranabahu
> <aj...@gmail.com> wrote:
> >
> > > Hi all,
> > > Ok let me summarize what has been discussed and see
> whether this is
> > > correct
> > >
> > > 1. We make the getElement/TypebyQname method work
> properly. i.e. it
> > > searches through all the imported schemas 2. We introduce
> > > getElement/TypebyName which takes a string and only looks
> within the
> > > local schema
> > >
> > > we can actually solve the getRefElement problem if we do the
> > > getElementbyQname right.
> > >
> > > apart from this I think there are a few minor fixes we
> need to make
> > > and that should be enough for the next RC.
> > >
> > >
> > > Ajith
> > >
> > > On 11/5/07, Amila Suriarachchi
> <am...@gmail.com> wrote:
> > > > On 11/2/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> > > > >
> > > > > Hi Amila:
> > > > >
> > > > > Amila Suriarachchi wrote:
> > > > > >> What I'm really asking is why do you need to look anything
> > > > > >> (from a foreign namespace) up by name, when the
> object model
> > > > > >> lets you just
> > > walk
> > > > > >> the objects directly?
> > > > > >
> > > > > > here the problem is it does not allow. if you go
> and see the
> > > > > > XmlSchemaElement class only method
> > > > > > getRefName() is available. it does not have a method to get
> > > > > > the
> > > > > referenced
> > > > > > Element.
> > > > >
> > > > > Well, should we add that ability then?
> > > > >
> > > > > XmlSchemaElement realElement = element.getRefElement();
> > > >
> > > >
> > > > +1. but I am not sure the implementation problems as Benson has
> > > mentioned.
> > > > Anyway I belive this should go to next release.
> > > >
> > > > > The above senario (which I mentioned in earlier mail) is
> > > > > appliced when
> > > > > > getting
> > > > > > 1. Elements
> > > > > > 2, Named types
> > > > > > 3. Attributes
> > > > > > 4 Attribute Groups
> > > > > > 5. Goups
> > > > >
> > > > > OK, so what do people think of the suggestion that we fix the
> > > > > buggy method and perhaps add a new
> getElementByName(String) to
> > > > > get local elements?
> > > >
> > > >
> > > > +1. for change the getElementByName(QName) and add a new method
> > > > getElementByName(String).
> > > >
> > > > if no -1s, Ajith could you please start a vote with a new RC?
> > > >
> > > > Amila.
> > > >
> > > > --Glen
> > > > >
> > > > >
> ----------------------------------------------------------------
> > > > > ----- To unsubscribe, e-mail:
> > > > > commons-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail:
> commons-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Amila Suriarachchi,
> > > > WSO2 Inc.
> > > >
> > >
> > >
> > > --
> > > Ajith Ranabahu
> > >
> > > Reading, after a certain age, diverts the mind too much from its
> > > creative pursuits. Any man who reads too much and uses
> his own brain
> > > too little falls into lazy habits of thinking - Albert Einstein
> > >
> > >
> --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: commons-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
> >
>
>
>
> --
> Ajith Ranabahu
>
> Reading, after a certain age, diverts the mind too much from
> its creative pursuits. Any man who reads too much and uses
> his own brain too little falls into lazy habits of thinking -
> Albert Einstein
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] [Vote] Time for a release - take 2
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi all,
I'll be doing the changes to both the trunk and the branch. I suppose
everybody agrees to the list I've posted ?
>From the list of Jiras we have eight (8) unresolved issues. I estimate
that these will take about two days for me to tackle. Hence the
release candidate can be expected around the weekend.
Ajith
On Nov 28, 2007 11:42 PM, Amila Suriarachchi
<am...@gmail.com> wrote:
> hi ajith,
> have you done these changes to the trunk.
>
> Amila.
>
>
> On Nov 6, 2007 4:29 AM, Ajith Ranabahu <aj...@gmail.com> wrote:
>
> > Hi all,
> > Ok let me summarize what has been discussed and see whether this is
> > correct
> >
> > 1. We make the getElement/TypebyQname method work properly. i.e. it
> > searches through all the imported schemas
> > 2. We introduce getElement/TypebyName which takes a string and only
> > looks within the local schema
> >
> > we can actually solve the getRefElement problem if we do the
> > getElementbyQname right.
> >
> > apart from this I think there are a few minor fixes we need to make
> > and that should be enough for the next RC.
> >
> >
> > Ajith
> >
> > On 11/5/07, Amila Suriarachchi <am...@gmail.com> wrote:
> > > On 11/2/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> > > >
> > > > Hi Amila:
> > > >
> > > > Amila Suriarachchi wrote:
> > > > >> What I'm really asking is why do you need to look anything (from a
> > > > >> foreign namespace) up by name, when the object model lets you just
> > walk
> > > > >> the objects directly?
> > > > >
> > > > > here the problem is it does not allow. if you go and see the
> > > > > XmlSchemaElement class only method
> > > > > getRefName() is available. it does not have a method to get the
> > > > referenced
> > > > > Element.
> > > >
> > > > Well, should we add that ability then?
> > > >
> > > > XmlSchemaElement realElement = element.getRefElement();
> > >
> > >
> > > +1. but I am not sure the implementation problems as Benson has
> > mentioned.
> > > Anyway I belive this should go to next release.
> > >
> > > > The above senario (which I mentioned in earlier mail) is appliced when
> > > > > getting
> > > > > 1. Elements
> > > > > 2, Named types
> > > > > 3. Attributes
> > > > > 4 Attribute Groups
> > > > > 5. Goups
> > > >
> > > > OK, so what do people think of the suggestion that we fix the buggy
> > > > method and perhaps add a new getElementByName(String) to get local
> > > > elements?
> > >
> > >
> > > +1. for change the getElementByName(QName) and add a new method
> > > getElementByName(String).
> > >
> > > if no -1s, Ajith could you please start a vote with a new RC?
> > >
> > > Amila.
> > >
> > > --Glen
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: commons-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Amila Suriarachchi,
> > > WSO2 Inc.
> > >
> >
> >
> > --
> > Ajith Ranabahu
> >
> > Reading, after a certain age, diverts the mind too much from its
> > creative pursuits. Any man who reads too much and uses his own brain
> > too little falls into lazy habits of thinking - Albert Einstein
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: commons-dev-help@ws.apache.org
> >
> >
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
--
Ajith Ranabahu
Reading, after a certain age, diverts the mind too much from its
creative pursuits. Any man who reads too much and uses his own brain
too little falls into lazy habits of thinking - Albert Einstein
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] [Vote] Time for a release - take 2
Posted by Amila Suriarachchi <am...@gmail.com>.
hi ajith,
have you done these changes to the trunk.
Amila.
On Nov 6, 2007 4:29 AM, Ajith Ranabahu <aj...@gmail.com> wrote:
> Hi all,
> Ok let me summarize what has been discussed and see whether this is
> correct
>
> 1. We make the getElement/TypebyQname method work properly. i.e. it
> searches through all the imported schemas
> 2. We introduce getElement/TypebyName which takes a string and only
> looks within the local schema
>
> we can actually solve the getRefElement problem if we do the
> getElementbyQname right.
>
> apart from this I think there are a few minor fixes we need to make
> and that should be enough for the next RC.
>
>
> Ajith
>
> On 11/5/07, Amila Suriarachchi <am...@gmail.com> wrote:
> > On 11/2/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> > >
> > > Hi Amila:
> > >
> > > Amila Suriarachchi wrote:
> > > >> What I'm really asking is why do you need to look anything (from a
> > > >> foreign namespace) up by name, when the object model lets you just
> walk
> > > >> the objects directly?
> > > >
> > > > here the problem is it does not allow. if you go and see the
> > > > XmlSchemaElement class only method
> > > > getRefName() is available. it does not have a method to get the
> > > referenced
> > > > Element.
> > >
> > > Well, should we add that ability then?
> > >
> > > XmlSchemaElement realElement = element.getRefElement();
> >
> >
> > +1. but I am not sure the implementation problems as Benson has
> mentioned.
> > Anyway I belive this should go to next release.
> >
> > > The above senario (which I mentioned in earlier mail) is appliced when
> > > > getting
> > > > 1. Elements
> > > > 2, Named types
> > > > 3. Attributes
> > > > 4 Attribute Groups
> > > > 5. Goups
> > >
> > > OK, so what do people think of the suggestion that we fix the buggy
> > > method and perhaps add a new getElementByName(String) to get local
> > > elements?
> >
> >
> > +1. for change the getElementByName(QName) and add a new method
> > getElementByName(String).
> >
> > if no -1s, Ajith could you please start a vote with a new RC?
> >
> > Amila.
> >
> > --Glen
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: commons-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
> >
>
>
> --
> Ajith Ranabahu
>
> Reading, after a certain age, diverts the mind too much from its
> creative pursuits. Any man who reads too much and uses his own brain
> too little falls into lazy habits of thinking - Albert Einstein
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [XmlSchema] [Vote] Time for a release - take 2
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi all,
Ok let me summarize what has been discussed and see whether this is correct
1. We make the getElement/TypebyQname method work properly. i.e. it
searches through all the imported schemas
2. We introduce getElement/TypebyName which takes a string and only
looks within the local schema
we can actually solve the getRefElement problem if we do the
getElementbyQname right.
apart from this I think there are a few minor fixes we need to make
and that should be enough for the next RC.
Ajith
On 11/5/07, Amila Suriarachchi <am...@gmail.com> wrote:
> On 11/2/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> >
> > Hi Amila:
> >
> > Amila Suriarachchi wrote:
> > >> What I'm really asking is why do you need to look anything (from a
> > >> foreign namespace) up by name, when the object model lets you just walk
> > >> the objects directly?
> > >
> > > here the problem is it does not allow. if you go and see the
> > > XmlSchemaElement class only method
> > > getRefName() is available. it does not have a method to get the
> > referenced
> > > Element.
> >
> > Well, should we add that ability then?
> >
> > XmlSchemaElement realElement = element.getRefElement();
>
>
> +1. but I am not sure the implementation problems as Benson has mentioned.
> Anyway I belive this should go to next release.
>
> > The above senario (which I mentioned in earlier mail) is appliced when
> > > getting
> > > 1. Elements
> > > 2, Named types
> > > 3. Attributes
> > > 4 Attribute Groups
> > > 5. Goups
> >
> > OK, so what do people think of the suggestion that we fix the buggy
> > method and perhaps add a new getElementByName(String) to get local
> > elements?
>
>
> +1. for change the getElementByName(QName) and add a new method
> getElementByName(String).
>
> if no -1s, Ajith could you please start a vote with a new RC?
>
> Amila.
>
> --Glen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: commons-dev-help@ws.apache.org
> >
> >
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
--
Ajith Ranabahu
Reading, after a certain age, diverts the mind too much from its
creative pursuits. Any man who reads too much and uses his own brain
too little falls into lazy habits of thinking - Albert Einstein
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] [Vote] Time for a release - take 2
Posted by Amila Suriarachchi <am...@gmail.com>.
On 11/2/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>
> Hi Amila:
>
> Amila Suriarachchi wrote:
> >> What I'm really asking is why do you need to look anything (from a
> >> foreign namespace) up by name, when the object model lets you just walk
> >> the objects directly?
> >
> > here the problem is it does not allow. if you go and see the
> > XmlSchemaElement class only method
> > getRefName() is available. it does not have a method to get the
> referenced
> > Element.
>
> Well, should we add that ability then?
>
> XmlSchemaElement realElement = element.getRefElement();
+1. but I am not sure the implementation problems as Benson has mentioned.
Anyway I belive this should go to next release.
> The above senario (which I mentioned in earlier mail) is appliced when
> > getting
> > 1. Elements
> > 2, Named types
> > 3. Attributes
> > 4 Attribute Groups
> > 5. Goups
>
> OK, so what do people think of the suggestion that we fix the buggy
> method and perhaps add a new getElementByName(String) to get local
> elements?
+1. for change the getElementByName(QName) and add a new method
getElementByName(String).
if no -1s, Ajith could you please start a vote with a new RC?
Amila.
--Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [XmlSchema] [Vote] Time for a release - take 2
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Amila:
Amila Suriarachchi wrote:
>> What I'm really asking is why do you need to look anything (from a
>> foreign namespace) up by name, when the object model lets you just walk
>> the objects directly?
>
> here the problem is it does not allow. if you go and see the
> XmlSchemaElement class only method
> getRefName() is available. it does not have a method to get the referenced
> Element.
Well, should we add that ability then?
XmlSchemaElement realElement = element.getRefElement();
> The above senario (which I mentioned in earlier mail) is appliced when
> getting
> 1. Elements
> 2, Named types
> 3. Attributes
> 4 Attribute Groups
> 5. Goups
OK, so what do people think of the suggestion that we fix the buggy
method and perhaps add a new getElementByName(String) to get local elements?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] [Vote] Time for a release - take 2
Posted by Amila Suriarachchi <am...@gmail.com>.
On 10/31/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>
> Hi Amila:
>
> Amila Suriarachchi wrote:
> > On 10/30/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> >> So, what I'd like to do is:
> >>
> >> * (best solution) Fix the problem with the API, and don't bother
> >> providing an option for "local" searches... why would you want/need
> such
> >> a thing? (if someone can provide a solid use-case I'm flexible on this)
> >> Fix ADB to use the new code.
> >
> > I am agree with your argument about the method signature. And also if I
> am
> > extending it
> > ByName part can also omited since there is nothing other than the name
> which
> > can uniquely identify the Element or type.
>
> +1, you are totally right, and if I was building from scratch now I'd
> just call the methods getElement()/getType(). But since we already have
> the API, I'm not sure we should change the name just for that. :)
>
> > Lets take this senario to explain why ADB needs the parent schema.
> > Lets say we have three elements
> > E1(S1) refers to E2(S2) (in different schema)
> > E2(S2) refers to E3(S3) (in different schema)
> >
> > What currently ADB does is it
> > first find the schema of the E2 (i.e. S2) starting with the
> > S1. (since it should be possible to find it serching through imports and
> > includes starting from S1)
>
> Well, hang on a sec. Can you explain to me exactly what it's doing here
> (or point me at the code in question)? I would think you'd read in the
> schema and then end up walking the elements inside an
> XmlSchemaComplexType - which typically means using getItems() on the
> contained sequence. To be clear, I'm imagining this:
>
> <schema targetNamespace="ns1">
> <element name="E1">
> <complexType>
> <sequence>
> <element ref="ns2:E2"/>
> </sequence>
> </complexType>
> </element>
> </schema>
>
> So my question here is why do you need the actual XmlSchema object at
> all for S2? Don't you just end up with an XmlSchemaElement for E2 when
> you're walking the structure of E1?
>
> What I'm really asking is why do you need to look anything (from a
> foreign namespace) up by name, when the object model lets you just walk
> the objects directly?
here the problem is it does not allow. if you go and see the
XmlSchemaElement class only method
getRefName() is available. it does not have a method to get the referenced
Element.
The above senario (which I mentioned in earlier mail) is appliced when
getting
1. Elements
2, Named types
3. Attributes
4 Attribute Groups
5. Goups
Thanks.
Amila.
> > So you can argue that why E3 can not be found starting with S1 as well?
> yes
> > this is correct, the only thing it is inefficient since we always have
> to
> > start search from the bottom.
> > therefore I think it is nice to have getElementByName(String) method as
> > well.
>
> +1, seems reasonable.
>
> Thanks,
> --Glen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [XmlSchema] [Vote] Time for a release - take 2
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Amila:
Amila Suriarachchi wrote:
> On 10/30/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>> So, what I'd like to do is:
>>
>> * (best solution) Fix the problem with the API, and don't bother
>> providing an option for "local" searches... why would you want/need such
>> a thing? (if someone can provide a solid use-case I'm flexible on this)
>> Fix ADB to use the new code.
>
> I am agree with your argument about the method signature. And also if I am
> extending it
> ByName part can also omited since there is nothing other than the name which
> can uniquely identify the Element or type.
+1, you are totally right, and if I was building from scratch now I'd
just call the methods getElement()/getType(). But since we already have
the API, I'm not sure we should change the name just for that. :)
> Lets take this senario to explain why ADB needs the parent schema.
> Lets say we have three elements
> E1(S1) refers to E2(S2) (in different schema)
> E2(S2) refers to E3(S3) (in different schema)
>
> What currently ADB does is it
> first find the schema of the E2 (i.e. S2) starting with the
> S1. (since it should be possible to find it serching through imports and
> includes starting from S1)
Well, hang on a sec. Can you explain to me exactly what it's doing here
(or point me at the code in question)? I would think you'd read in the
schema and then end up walking the elements inside an
XmlSchemaComplexType - which typically means using getItems() on the
contained sequence. To be clear, I'm imagining this:
<schema targetNamespace="ns1">
<element name="E1">
<complexType>
<sequence>
<element ref="ns2:E2"/>
</sequence>
</complexType>
</element>
</schema>
So my question here is why do you need the actual XmlSchema object at
all for S2? Don't you just end up with an XmlSchemaElement for E2 when
you're walking the structure of E1?
What I'm really asking is why do you need to look anything (from a
foreign namespace) up by name, when the object model lets you just walk
the objects directly?
> So you can argue that why E3 can not be found starting with S1 as well? yes
> this is correct, the only thing it is inefficient since we always have to
> start search from the bottom.
> therefore I think it is nice to have getElementByName(String) method as
> well.
+1, seems reasonable.
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] [Vote] Time for a release - take 2
Posted by Amila Suriarachchi <am...@gmail.com>.
On 10/30/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>
> Hi Ajith:
>
> Ajith Ranabahu wrote:
> > 1. Added two new methods
> > public XmlSchemaElement getElementByName(QName name, boolean deep)
> > public XmlSchemaType getTypeByName(QName name, boolean deep)
> >
> > These two methods were added to circumvent the issue of deep search
> > and also not to break the existing code. The older methods however are
> > deprecated. This seemed to be the path of least resistance but
> > suggestions are welcome :)
>
> I am really not a fan of this solution. :(
>
> Here's my thinking. It seems to me that if we intended a single
> XmlSchema to only hold locally defined items (elements/types), we would
> only need a method like getElementByName(String), where the argument was
> the NCName - the namespace could always be assumed to be the namespace
> of the schema itself. But in fact the API has a QName argument, which
> to me implies that the intent is to enable access to anything to which
> the XmlSchema object itself has access... in other words all the
> imported elements/types from other namespaces as well. The object model
> is meant to map closely to the spec.
>
> If you accept that logic, then it's pretty clear that having
> getElementByName(QName) actually only search the local schema without
> regard for imports is plain and simply a *bug*. Bugs should be fixed.
> We should have a test case for this, etc. And if something like ADB
> relies on the broken behavior then that code is *also* buggy and should
> be fixed.
>
> So, what I'd like to do is:
>
> * (best solution) Fix the problem with the API, and don't bother
> providing an option for "local" searches... why would you want/need such
> a thing? (if someone can provide a solid use-case I'm flexible on this)
> Fix ADB to use the new code.
I am agree with your argument about the method signature. And also if I am
extending it
ByName part can also omited since there is nothing other than the name which
can uniquely identify the Element or type.
Lets take this senario to explain why ADB needs the parent schema.
Lets say we have three elements
E1(S1) refers to E2(S2) (in different schema)
E2(S2) refers to E3(S3) (in different schema)
What currently ADB does is it
first find the schema of the E2 (i.e. S2) starting with the
S1. (since it should be possible to find it serching through imports and
includes starting from S1)
Then get the element from the schema and when finding E3 it starts with S2
(previously found parent schema). This is why it needs the parent schema.
So you can argue that why E3 can not be found starting with S1 as well? yes
this is correct, the only thing it is inefficient since we always have to
start search from the bottom.
therefore I think it is nice to have getElementByName(String) method as
well.
Amila.
* (not as good) Fix the problem with the current API, so
> getElementByName(QName) has the correct behavior (incl. searching
> imports), and ALSO provide a new getElementByName(QName, boolean) (or
> even better, getLocalElementByName(QName)) to enable the "local only"
> searching.
>
> Either of these, to my mind, would be better than the current state.
>
> Let's please fix this right, as these APIs are going to be with us a
> long time.
>
> Thoughts/comments?
>
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [XmlSchema] [Vote] Time for a release - take 2
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Ajith:
Ajith Ranabahu wrote:
> 1. Added two new methods
> public XmlSchemaElement getElementByName(QName name, boolean deep)
> public XmlSchemaType getTypeByName(QName name, boolean deep)
>
> These two methods were added to circumvent the issue of deep search
> and also not to break the existing code. The older methods however are
> deprecated. This seemed to be the path of least resistance but
> suggestions are welcome :)
I am really not a fan of this solution. :(
Here's my thinking. It seems to me that if we intended a single
XmlSchema to only hold locally defined items (elements/types), we would
only need a method like getElementByName(String), where the argument was
the NCName - the namespace could always be assumed to be the namespace
of the schema itself. But in fact the API has a QName argument, which
to me implies that the intent is to enable access to anything to which
the XmlSchema object itself has access... in other words all the
imported elements/types from other namespaces as well. The object model
is meant to map closely to the spec.
If you accept that logic, then it's pretty clear that having
getElementByName(QName) actually only search the local schema without
regard for imports is plain and simply a *bug*. Bugs should be fixed.
We should have a test case for this, etc. And if something like ADB
relies on the broken behavior then that code is *also* buggy and should
be fixed.
So, what I'd like to do is:
* (best solution) Fix the problem with the API, and don't bother
providing an option for "local" searches... why would you want/need such
a thing? (if someone can provide a solid use-case I'm flexible on this)
Fix ADB to use the new code.
* (not as good) Fix the problem with the current API, so
getElementByName(QName) has the correct behavior (incl. searching
imports), and ALSO provide a new getElementByName(QName, boolean) (or
even better, getLocalElementByName(QName)) to enable the "local only"
searching.
Either of these, to my mind, would be better than the current state.
Let's please fix this right, as these APIs are going to be with us a
long time.
Thoughts/comments?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org