I'm curious as to why xsd:choice groups should be avoided. Are there
interoperability or Java<->XML marshalling issues? BTW, the use of a
choice group is only one option anyway. Another way, it seems, that
doesn't use xsd:choice follows below. It unfortunately requires a little
more work on the part of the programmer and some sort of implicit
processing rule such as 'if search-expression' element present, ignore
search attribute and value, which could be both set to nil.
I don't like this as much but it eliminates the xsd:choice. Anne, is
this better?
<xsd:complexType name="SearchCriteria">
<xsd:sequence>
<xsd:element name="search-attribute" type="xsd:string"
nillable="true"/> <!-- for example, "id", "HouseId", "name" -->
<xsd:element name="search-attribute-value"
type="xsd:string" nillable="true"/> <!-- for example "12345", "12345
Main St.", "John Smith" -->
</xsd:sequence>
<xsd:element name="search-expression" type="xsd:string"
minOccurs="0"/> <!-- can pass in any search expression that is
meaningful to your service (e.g. regex, sql, etc.) -->
</xsd:complexType>
Thanks.
-----Original Message-----
From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]
Sent: Friday, April 08, 2005 4:05 PM
To: Hittesdorf,Michael
Subject: Re: Which is a better approach to avoid polymorphism and
inheritance
Nice idea, but you should avoid <xsd:choice> groups.
Could you put an Id attribute into the ContentRealization type? That
way the client knows ahead of time what type to request.
Anne
On Apr 8, 2005 4:14 PM, Hittesdorf,Michael <[EMAIL PROTECTED]>
wrote:
>
> If I understand your goal and problem correctly, I would suggesting
> defining a 'SearchCriteria' type and passing it as a parameter to your
> 'find' operation. It could contain a search expression or
alternatively,
> and more simply, just a search attribute and a search value? See
below:
>
> <xsd:complexType name="SearchCriteria">
> <xsd:choice>
> <xsd:sequence>
> <xsd:element name="search-attribute"
> type="xsd:string"/> <!-- for example, "id", "HouseId", "name" -->
> <xsd:element name="search-attribute-value"
> type="xsd:string"/> <!-- for example "12345", "12345 Main St.", "John
> Smith" -->
> </xsd:sequence>
> <xsd:element name="search-expression" type="xsd:string"/> <!--
> can pass in any search expression that is meaningful to your service
> (e.g. regex, sql, etc.) -->
> </xsd:choice>
> </xsd:complexType>
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 08, 2005 2:49 PM
> To: axis-user@ws.apache.org
> Subject: Re: Which is a better approach to avoid polymorphism and
> inheritance
>
> Definitely go with the first approach. JAX-RPC does not require
> support for <xsd:union>, and very few products support it.
>
> Anne
>
> On Apr 6, 2005 4:36 PM, Soti, Dheeraj <[EMAIL PROTECTED]> wrote:
> >
> >
> > Hi,
> >
> > I have class structure like as shown below. I am using doc/literal
> wrapped
> > style and I don't want to expose concepts like polymorphism,
> inheritance and
> > overloading in my service methods. There are two ways to handle
this:
> > Define two different complex elements for each type of content. The
> > advantage is its very clear and simple. The disadvantage is that
there
> are
> > many calls like findById, findByHouseId, findByName etc. So I'll end
> up
> > writing duplicate set of calls for each type of content
> > Define a single complex element with union of the fields from both
and
> > introduce a field to store type. The advantage is that I only need
> single
> > set of calls. The disadvantage is the additional type. There is a
> saying
> > that "Adding type means killing your object".
> >
> >
> > I understand that this is not really axis related question but I
will
> highly
> > appreciate if some would like to share his experience with me.
> >
> > Thanks
> >
> > Dheeraj Soti
> >
> >
> > Content
> > |
> > -----------------------------------------
> > | |
> > CommercialContent ProgramContent
>
> E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message
and any attachments are intended solely for the
> addressee(s) and may contain confidential and/or legally privileged
information. If you are not the
> intended recipient of this message or if this message has been
addressed to you in error, please
> immediately alert the sender by reply e-mail and then delete this
message and any attachments. If you
> are not the intended recipient, you are notified that any use,
dissemination, distribution, copying, or
> storage of this message or any attachment is strictly prohibited.
>
E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any
attachments are intended solely for the
addressee(s) and may contain confidential and/or legally privileged
information. If you are not the
intended recipient of this message or if this message has been addressed to you
in error, please
immediately alert the sender by reply e-mail and then delete this message and
any attachments. If you
are not the intended recipient, you are notified that any use, dissemination,
distribution, copying, or
storage of this message or any attachment is strictly prohibited.
