You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Maryam Moazeni <mm...@gmail.com> on 2006/07/04 16:22:04 UTC

Re: [axis2] Google SoC: ADB Project

Hi all,

Regarding the complex content restriction:

In the case that the *restriction* base type is a *complex type*, the
derived class overrides the getter and setter corresponding to restricted
elements, but how about when the *restriction* base type is a *simple type*?
simple types doesn't have elements !!

in the current implementation for the *extension* of a *simple type, *the
derived class extends "org.apache.axiom.om.OMElement" and its elements are
added to the class.
but seems there's a different story for restriction.

Any Thoughts?

Thanks,
Maryam


>
>  Hi Ajith,
>
> Thanks for sharing your thoughts,
>
> For (1), (2) I was thinking of what you mentioned. So, you say we
> shouldn't have the
> real Java inheritance here because of the existence of primitive types,
> right?
>
>  Well, I have already started testing some simple schemas with
> the XMLBeans. That seems to be the only source for me :)
>
> Thanks,
>  Maryam
>
>
>  On 6/22/06, Ajith Ranabahu < ajith.ranabahu@gmail.com> wrote:
>
> > Hi Maryam,
> > I've had the thoughts for the supporting of simple content extension
> > and restriction and complex content restriction (We already support
> > complex content extension partially)
> >
> > 1. simple content extension
> > This should generate a seperate class that contains the base type as
> > a field. for the variations, there would be  other fields generated
> > into the class (say in the case of attributes). Note that extending
> > the classes would not work since there can be java primitives (like
> > int and boolean) and even if mapped to a class the class may not be
> > extensible (like the java.lang.String which is final)
> >
> > 2.  simple content restriction
> > This should be the same as the extension case but now it would have
> > conditions generated into the the setter method of the base field. Say
> > in the case of enums there should be a list of constants and the
> > constants should be checked against the input value when setting the
> > value. Similar check can be done for the regular expressions.
> >
> > 3. Complex content restriction
> >   Hmm... this is somewhat tricky. What I see is that we can extend
> > the generated class just like for extension but overrride the setters
> > depending on the restriction.
> >
> > One thing you can do is to see what XMLbeans does for this. Only thing
> > is they generate classes all over the place (:)) and it might be a bit
> > hard to figure out what is what :)
> >
> > Others please add your thoughts into this.
> >
> > Ajith
> >
> > On 6/21/06, Maryam Moazeni < mmoazeni@gmail.com> wrote:
> > >
> > >
> > > Hi All,
> > >
> > > I'm doing a project for improving ADB for Google Summer of Code,
> > > At this point, I'm trying to implement the
> > >
> > > Simple Content Restriction and Extension
> > > Complex Content Restriction and Extension
> > > I'd like to receive sugestions from Axis2 Developers for implementing
> > these
> > > features.
> > > Any suggestions?
> > >
> > > Thanks,
> > >
> > >
> > > Maryam Moazeni
> >
> >
> > --
> > Ajith Ranabahu
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>

Re: [axis2] Google SoC: ADB Project

Posted by Maryam Moazeni <mm...@gmail.com>.
Hi All,

I still need comments on the implementation part !!
Dennis, Thanks for the reply, it was really helpful !!

-Maryam


On 7/9/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>
> Hi Maryam,
>
> As I understand restriction, the basic requirement is that all instances
> matched by the restriction must also be valid in the base type. So yes,
> you can replace types with subtypes, and you can definitely remove
> attributes that weren't required in the base type (or substitute
> subtypes for their their types), or change optional attributes to
> required or prohibited. You can also add specific (optional) attributes
> if the base type has an xs:anyAttribute wildcard.
>
> Note that the structure of the definition can change, too - for
> instance, a xs:choice that has minOccurs='1' and maxOccurs='1' can be
> replaced by any one of the elements in the choice. You can also replace
> an xs:choice with maxOccurs>1 with an xs:sequence containing up to
> maxOccurs elements, etc.
>
> So basically complex type restriction is a mess from the standpoint of
> anyone working with programming languages. I recommend against using it
> in schemas that are intended for communicating data between programs.
> But since it's part of the schema standard people will use it, and those
> of us working with XML have to deal with it somehow.
>
> - Dennis
>
> Maryam Moazeni wrote:
> > Hi Dennis,
> >
> > Thanks for the reply.
> > so your saying that types can be replaced by subtypes. For
> > instance, xs:int can be replaced by xs:int that is restricted between
> > 0 and 100, right?
> >
> > Also what about *attributes*, a restricted type could have less
> > attributes right? How a restricted type can change taking attributes
> > into consideration?
> >
> > Thanks,
> > Maryam
> >
> >
> > On 7/9/06, *Dennis Sosnoski* <dms@sosnoski.com
> > <ma...@sosnoski.com>> wrote:
> >
> >     Hi Maryam,
> >
> >     Sounds about right, except that for (4) any element can be given a
> >     more
> >     specific type than in the base type definition (so an element
> >     typed as
> >     xs:string could instead be made xs:token, for instance), and for
> >     (5) an
> >     xs:any with maxOccurs > 1 could be replaced by multiple elements (or
> >     elements and a new xs:any).
> >
> >     - Dennis
> >
> >     Dennis M. Sosnoski
> >     SOA, Web Services, and XML
> >     Training and Consulting
> >     http://www.sosnoski.com - http://www.sosnoski.co.nz
> >     Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
> >
> >
> >
> >     Maryam Moazeni wrote:
> >     >
> >     > Hi All,
> >     >
> >     > Regarding the implementation of the support for complex content
> >     > restriction:
> >     > I need to know in what cases an element could be restricted. I
> have
> >     > some observations, but I'd like to see if any one can add more
> >     to this.
> >     >
> >     > 1) Removal of an optional element.
> >     > 2) Reducing the "maxOccurs".
> >     > 3) Increasing the "minOccurs".
> >     > 4) Giving an element a specific type, in the case the element
> >     > has "anyType" as its type
> >     >     in the base type.
> >     > 5) In the case we have "any" in the base type, and we restrict the
> >     > elements by attributes
> >     >     of "any" such as "minOccurs" and "maxOccurs".
> >     >
> >     > Please correct me if I'm wrong and add your opinions.
> >     >
> >     > For implementing this I thought I should check all the elements
> >     listed
> >     > in the restricted type with elements of the base type for the
> named
> >     > conditions, if any of them differs, the element goes to the list
> of
> >     > restricted elements.
> >     >
> >     > Also, I thought with any approach that I choose, I have to edit
> the
> >     > DOM tree created from populating the parent meta info. But, it
> >     seems the
> >     >
> >     > Element root = model.getDocumentElement();
> >     >
> >     > return null when I'm trying to access the model's root element.
> >     >
> >     > In my approach, I thought maybe I can add "restricted" node to the
> >     > root node, per restricted elements and also edit the "property"
> >     nodes
> >     > according to the restricted elements to make sure that they're not
> >     > marked as "isInherited" or maybe we can remove them from the tree.
> >     >
> >     > Also I need to know what will happen in the case, base type is
> >     of type
> >     > "anyType"?
> >     >
> >     > I would appreciate if you share your thoughts with me.
> >     >
> >     > Thanks,
> >     > Maryam
> >     >
> >     >
> >     > On 7/4/06, *Maryam Moazeni* <mmoazeni@gmail.com
> >     <ma...@gmail.com>
> >     > <mailto:mmoazeni@gmail.com <ma...@gmail.com>>> wrote:
> >     >
> >     >     Hi Dennis,
> >     >
> >     >     That's what I wanted to make sure !!! Thanks.
> >     >
> >     >     Maryam
> >     >
> >     >
> >     >     On 7/4/06, *Dennis Sosnoski* < dms@sosnoski.com
> >     <ma...@sosnoski.com>
> >     >     <mailto:dms@sosnoski.com <ma...@sosnoski.com>>> wrote:
> >     >
> >     >         Hi Maryam,
> >     >
> >     >         This isn't a valid case. The only way to get
> >     complexContent from a
> >     >         simpleType is by using extension (since restriction says
> >     that
> >     >         you're
> >     >         only going to allow a subset of what the base type allows
> -
> >     >         which means
> >     >         that the restriction of a simpleType is always going to be
> >     >         simpleContent). Just to be sure, I tried this in Oxygen:
> >     >
> >     >         <?xml version=" 1.0" encoding="UTF-8"?>
> >     >         <schema xmlns=" http://www.w3.org/2001/XMLSchema"
> >     >         targetNamespace="urn:a"
> >     >         xmlns:tns="urn:a">
> >     >         <simpleType name="x">
> >     >            <restriction base="decimal">
> >     >              <minExclusive value="0.0"/>
> >     >              <maxExclusive value ="100.0 "/>
> >     >            </restriction>
> >     >         </simpleType>
> >     >
> >     >         <complexType name="y">
> >     >            <complexContent>
> >     >              <restriction base="tns:x">
> >     >                <minExclusive value=" 1.0"/>
> >     >              </restriction>
> >     >            </complexContent>
> >     >         </complexType>
> >     >         </schema>
> >     >
> >     >         It gave the expected error:
> >     >
> >     >         SystemID: /usr/local/tools/oxygen6.2/Untitled1.xsd
> >     >         Location: 12:33
> >     >         Description: E src-ct.1: Complex Type Definition
> >     >         Representation Error
> >     >         for type 'y'.  When <complexContent> is used, the base
> type
> >     >         must be a
> >     >         complexType. 'x' is a simpleType.
> >     >         URL: http://www.w3.org/TR/xmlschema-1/#src-ct
> >     >
> >     >         - Dennis
> >     >
> >     >         Dennis M. Sosnoski
> >     >         SOA, Web Services, and XML
> >     >         Training and Consulting
> >     >         http://www.sosnoski.com <http://www.sosnoski.com/
> >     <http://www.sosnoski.com/>> -
> >     >         http://www.sosnoski.co.nz <http://www.sosnoski.co.nz/>
> >     >         Seattle, WA +1-425-296-6194 - Wellington, NZ
> +64-4-298-6117
> >     >
> >     >
> >     >
> >     >         Maryam Moazeni wrote:
> >     >         > Hi Ajith,
> >     >         >
> >     >         > actually I meant something else, I think what u
> mentioned
> >     >         here is a
> >     >         > SimpleTypeRestriction which I think is handeled in
> >     >         > processSimpleSchemaType(...), I'm not sure though.
> Please
> >     >         correct me
> >     >         > if I'm wrong.
> >     >         >
> >     >         > But what I asked is the case of Complex Content when:
> >     >         >
> >     >         > *restriction.getBaseTypeName() instanceof
> >     XmlSchemaSimpleType*
> >     >         >
> >     >         > For example:
> >     >         >
> >     >         > <simpleType name="x">
> >     >         >       <restriction base="number">
> >     >         >            <minExlusive value="0.0"/>
> >     >         >            <maxExlusive value =" 100.0"/>
> >     >         >       </restriction>
> >     >         > </simpleType>
> >     >         >
> >     >         > <complexType name="y">
> >     >         >     <complexContent>
> >     >         >        *<restriction base="tns:x">*
> >     >         > *          ....*
> >     >         > *       *</restriction>
> >     >         >      </complexContent>
> >     >         > </complexType>
> >     >         >
> >     >         > I'd like to know what will happen in this case.
> >     >         >
> >     >         > Thanks,
> >     >         > Maryam
> >     >         >
> >     >         >
> >     >         > On 7/4/06, *Ajith Ranabahu* < ajith.ranabahu@gmail.com
> >     <ma...@gmail.com>
> >     >         <mailto:ajith.ranabahu@gmail.com
> >     <ma...@gmail.com>>
> >     >         > <mailto: ajith.ranabahu@gmail.com
> >     <ma...@gmail.com>
> >     >         <mailto:ajith.ranabahu@gmail.com
> >     <ma...@gmail.com>>>> wrote:
> >     >         >
> >     >         >     Hi Maryam,
> >     >         >     What I thought as appropriate for the simple type
> >     is to
> >     >         wrap the
> >     >         >     necessary type in class and build the restriction
> >     logic
> >     >         into that
> >     >         >     class.
> >     >         >     For example think of a restriction based on
> xs:string
> >     >         with a pattern
> >     >         >     like the following
> >     >         >
> >     >         >     <xs:simpleType name="myType">
> >     >         >            <xs:restriction base="xs:string">
> >     >         >                     <xs:pattern value="\d"/>
> >     >         >            </xs:restriction>
> >     >         >     </xs:simpleType>
> >     >         >
> >     >         >     for this I suggest we generate a class MyType that
> >     wraps a
> >     >         >     java.lang.string. For the setter we can inserts a
> >     reg exp
> >     >         based
> >     >         >     checker that throws an exception (??) for a wrong
> >     value .
> >     >         How does
> >     >         >     that sound :)
> >     >         >
> >     >         >
> >     >         >     Ajith
> >     >         >
> >     >         >     On 7/4/06, Maryam Moazeni <mmoazeni@gmail.com
> >     <ma...@gmail.com>
> >     >         <mailto: mmoazeni@gmail.com <ma...@gmail.com>>
> >     >         >     <mailto: mmoazeni@gmail.com
> >     <ma...@gmail.com> <mailto:mmoazeni@gmail.com
> >     <ma...@gmail.com>>>>
> >     >         wrote:
> >     >         >     >
> >     >         >     > Hi all,
> >     >         >     >
> >     >         >     > Regarding the complex content restriction:
> >     >         >     >
> >     >         >     > In the case that the restriction base type is a
> >     complex
> >     >         type,
> >     >         >     the derived
> >     >         >     > class overrides the getter and setter
> >     corresponding to
> >     >         >     restricted elements,
> >     >         >     > but how about when the restriction base type is a
> >     >         simple type?
> >     >         >     simple types
> >     >         >     > doesn't have elements !!
> >     >         >     >
> >     >         >     > in the current implementation for the extension of
> a
> >     >         simple
> >     >         >     type, the
> >     >         >     > derived class extends "
> >     org.apache.axiom.om.OMElement "
> >     >         and its
> >     >         >     elements are
> >     >         >     > added to the class.
> >     >         >     > but seems there's a different story for
> >     restriction.
> >     >         >     >
> >     >         >     > Any Thoughts?
> >     >         >     >
> >     >         >     > Thanks,
> >     >         >     >
> >     >         >     > Maryam
> >     >         >     >
> >     >         >     >
> >     >         >     >
> >     >         >     > >
> >     >         >     > >
> >     >         >     > >
> >     >         >     > >
> >     >         >     > >
> >     >         >     > > Hi Ajith,
> >     >         >     > >
> >     >         >     > >
> >     >         >     > > Thanks for sharing your thoughts,
> >     >         >     > >
> >     >         >     > > For (1), (2) I was thinking of what you
> mentioned.
> >     >         So, you say we
> >     >         >     > shouldn't have the
> >     >         >     > > real Java inheritance here because of the
> >     existence of
> >     >         >     primitive types,
> >     >         >     > right?
> >     >         >     > >
> >     >         >     > >
> >     >         >     > > Well, I have already started testing some simple
> >     >         schemas with the
> >     >         >     > XMLBeans. That seems to be the only source for me
> :)
> >     >         >     > >
> >     >         >     > > Thanks,
> >     >         >     > >
> >     >         >     > >
> >     >         >     > > Maryam
> >     >         >     > >
> >     >         >     > >
> >     >         >     > >
> >     >         >     > >
> >     >         >     > > On 6/22/06, Ajith Ranabahu <
> >     ajith.ranabahu@gmail.com <ma...@gmail.com>
> >     >         <mailto:ajith.ranabahu@gmail.com
> >     <ma...@gmail.com>>
> >     >         >     <mailto:ajith.ranabahu@gmail.com
> >     <ma...@gmail.com>
> >     >         <mailto:ajith.ranabahu@gmail.com
> >     <ma...@gmail.com>>> > wrote:
> >     >         >     > >
> >     >         >     > > > Hi Maryam,
> >     >         >     > > > I've had the thoughts for the supporting of
> >     simple
> >     >         content
> >     >         >     extension
> >     >         >     > > > and restriction and complex content
> >     restriction (We
> >     >         already
> >     >         >     support
> >     >         >     > > > complex content extension partially)
> >     >         >     > > >
> >     >         >     > > > 1. simple content extension
> >     >         >     > > > This should generate a seperate class that
> >     contains
> >     >         the base
> >     >         >     type as
> >     >         >     > > > a field. for the variations, there would
> >     be  other
> >     >         fields
> >     >         >     generated
> >     >         >     > > > into the class (say in the case of
> attributes).
> >     >         Note that
> >     >         >     extending
> >     >         >     > > > the classes would not work since there can
> >     be java
> >     >         >     primitives (like
> >     >         >     > > > int and boolean) and even if mapped to a
> >     class the
> >     >         class may
> >     >         >     not be
> >     >         >     > > > extensible (like the java.lang.String which
> >     is final)
> >     >         >     > > >
> >     >         >     > > > 2.  simple content restriction
> >     >         >     > > > This should be the same as the extension
> >     case but
> >     >         now it
> >     >         >     would have
> >     >         >     > > > conditions generated into the the setter
> >     method of
> >     >         the base
> >     >         >     field. Say
> >     >         >     > > > in the case of enums there should be a list of
> >     >         constants and the
> >     >         >     > > > constants should be checked against the
> >     input value
> >     >         when
> >     >         >     setting the
> >     >         >     > > > value. Similar check can be done for the
> regular
> >     >         expressions.
> >     >         >     > > >
> >     >         >     > > > 3. Complex content restriction
> >     >         >     > > >   Hmm... this is somewhat tricky. What I see
> is
> >     >         that we can
> >     >         >     extend
> >     >         >     > > > the generated class just like for extension
> but
> >     >         overrride
> >     >         >     the setters
> >     >         >     > > > depending on the restriction.
> >     >         >     > > >
> >     >         >     > > > One thing you can do is to see what XMLbeans
> >     does
> >     >         for this.
> >     >         >     Only thing
> >     >         >     > > > is they generate classes all over the place
> >     (:)) and it
> >     >         >     might be a bit
> >     >         >     > > > hard to figure out what is what :)
> >     >         >     > > >
> >     >         >     > > > Others please add your thoughts into this.
> >     >         >     > > >
> >     >         >     > > > Ajith
> >     >         >     > > >
> >     >         >     > > > On 6/21/06, Maryam Moazeni <
> >     mmoazeni@gmail.com <ma...@gmail.com>
> >     >         <mailto:mmoazeni@gmail.com <ma...@gmail.com>>
> >     >         >     <mailto: mmoazeni@gmail.com
> >     <ma...@gmail.com> <mailto:mmoazeni@gmail.com
> >     <ma...@gmail.com>>>>
> >     >         wrote:
> >     >         >     > > > >
> >     >         >     > > > >
> >     >         >     > > > > Hi All,
> >     >         >     > > > >
> >     >         >     > > > > I'm doing a project for improving ADB for
> >     Google
> >     >         Summer of
> >     >         >     Code,
> >     >         >     > > > > At this point, I'm trying to implement the
> >     >         >     > > > >
> >     >         >     > > > > Simple Content Restriction and Extension
> >     >         >     > > > > Complex Content Restriction and Extension
> >     >         >     > > > > I'd like to receive sugestions from Axis2
> >     >         Developers for
> >     >         >     implementing
> >     >         >     > these
> >     >         >     > > > > features.
> >     >         >     > > > > Any suggestions?
> >     >         >     > > > >
> >     >         >     > > > > Thanks,
> >     >         >     > > > >
> >     >         >     > > > >
> >     >         >     > > > > Maryam Moazeni
> >     >         >     > > >
> >     >         >     > > >
> >     >         >     > > > --
> >     >         >     > > > Ajith Ranabahu
> >     >         >     > > >
> >     >         >     > > >
> >     >         >     >
> >     >         >
> >     >
> >
> ---------------------------------------------------------------------
> >     >
> >     >         >     > > > To unsubscribe, e-mail:
> >     >         >     > axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>
> >     >         <mailto:axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>>
> >     >         >     <mailto: axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>
> >     >         <mailto:axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>> >
> >     >         >     > > > For additional commands, e-mail:
> >     >         axis-dev-help@ws.apache.org
> >     <ma...@ws.apache.org>
> >     <mailto:axis-dev-help@ws.apache.org
> >     <ma...@ws.apache.org>>
> >     >         >     <mailto: axis-dev-help@ws.apache.org
> >     <ma...@ws.apache.org>
> >     >         <mailto:axis-dev-help@ws.apache.org
> >     <ma...@ws.apache.org>>>
> >     >         >     > > >
> >     >         >     > > >
> >     >         >     > >
> >     >         >     > >
> >     >         >     > >
> >     >         >     >
> >     >         >     >
> >     >         >
> >     >         >
> >     >         >     --
> >     >         >     Ajith Ranabahu
> >     >         >
> >     >         >
> >     >
> >
> ---------------------------------------------------------------------
> >     >
> >     >         >     To unsubscribe, e-mail:
> >     >         axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>
> >     >         <mailto: axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>>
> >     >         >     <mailto: axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>
> >     >         <mailto: axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>>>
> >     >         >     For additional commands, e-mail:
> >     >         axis-dev-help@ws.apache.org
> >     <ma...@ws.apache.org> <mailto:
> >     axis-dev-help@ws.apache.org <ma...@ws.apache.org>>
> >     >         >     <mailto:axis-dev-help@ws.apache.org
> >     <ma...@ws.apache.org>
> >     >         <mailto: axis-dev-help@ws.apache.org
> >     <ma...@ws.apache.org>>>
> >     >         >
> >     >         >
> >     >
> >     >
> >
> ---------------------------------------------------------------------
> >     >         To unsubscribe, e-mail:
> >     axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>
> >     >         <mailto:axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>>
> >     >         For additional commands, e-mail:
> >     axis-dev-help@ws.apache.org <ma...@ws.apache.org>
> >     >         <mailto:axis-dev-help@ws.apache.org
> >     <ma...@ws.apache.org>>
> >     >
> >     >
> >     >
> >
> >
> ---------------------------------------------------------------------
> >     To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>
> >     For additional commands, e-mail: axis-dev-help@ws.apache.org
> >     <ma...@ws.apache.org>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Re: [axis2] Google SoC: ADB Project

Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Maryam,

As I understand restriction, the basic requirement is that all instances 
matched by the restriction must also be valid in the base type. So yes, 
you can replace types with subtypes, and you can definitely remove 
attributes that weren't required in the base type (or substitute 
subtypes for their their types), or change optional attributes to 
required or prohibited. You can also add specific (optional) attributes 
if the base type has an xs:anyAttribute wildcard.

Note that the structure of the definition can change, too - for 
instance, a xs:choice that has minOccurs='1' and maxOccurs='1' can be 
replaced by any one of the elements in the choice. You can also replace 
an xs:choice with maxOccurs>1 with an xs:sequence containing up to 
maxOccurs elements, etc.

So basically complex type restriction is a mess from the standpoint of 
anyone working with programming languages. I recommend against using it 
in schemas that are intended for communicating data between programs. 
But since it's part of the schema standard people will use it, and those 
of us working with XML have to deal with it somehow.

  - Dennis

Maryam Moazeni wrote:
> Hi Dennis,
>  
> Thanks for the reply.
> so your saying that types can be replaced by subtypes. For 
> instance, xs:int can be replaced by xs:int that is restricted between 
> 0 and 100, right?
>  
> Also what about *attributes*, a restricted type could have less 
> attributes right? How a restricted type can change taking attributes 
> into consideration? 
>  
> Thanks,
> Maryam
>
>  
> On 7/9/06, *Dennis Sosnoski* <dms@sosnoski.com 
> <ma...@sosnoski.com>> wrote:
>
>     Hi Maryam,
>
>     Sounds about right, except that for (4) any element can be given a
>     more
>     specific type than in the base type definition (so an element
>     typed as
>     xs:string could instead be made xs:token, for instance), and for
>     (5) an
>     xs:any with maxOccurs > 1 could be replaced by multiple elements (or
>     elements and a new xs:any).
>
>     - Dennis
>
>     Dennis M. Sosnoski
>     SOA, Web Services, and XML
>     Training and Consulting
>     http://www.sosnoski.com - http://www.sosnoski.co.nz
>     Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
>
>
>
>     Maryam Moazeni wrote:
>     >
>     > Hi All,
>     >
>     > Regarding the implementation of the support for complex content
>     > restriction:
>     > I need to know in what cases an element could be restricted. I have
>     > some observations, but I'd like to see if any one can add more
>     to this.
>     >
>     > 1) Removal of an optional element.
>     > 2) Reducing the "maxOccurs".
>     > 3) Increasing the "minOccurs".
>     > 4) Giving an element a specific type, in the case the element
>     > has "anyType" as its type
>     >     in the base type.
>     > 5) In the case we have "any" in the base type, and we restrict the
>     > elements by attributes
>     >     of "any" such as "minOccurs" and "maxOccurs".
>     >
>     > Please correct me if I'm wrong and add your opinions.
>     >
>     > For implementing this I thought I should check all the elements
>     listed
>     > in the restricted type with elements of the base type for the named
>     > conditions, if any of them differs, the element goes to the list of
>     > restricted elements.
>     >
>     > Also, I thought with any approach that I choose, I have to edit the
>     > DOM tree created from populating the parent meta info. But, it
>     seems the
>     >
>     > Element root = model.getDocumentElement();
>     >
>     > return null when I'm trying to access the model's root element.
>     >
>     > In my approach, I thought maybe I can add "restricted" node to the
>     > root node, per restricted elements and also edit the "property"
>     nodes
>     > according to the restricted elements to make sure that they're not
>     > marked as "isInherited" or maybe we can remove them from the tree.
>     >
>     > Also I need to know what will happen in the case, base type is
>     of type
>     > "anyType"?
>     >
>     > I would appreciate if you share your thoughts with me.
>     >
>     > Thanks,
>     > Maryam
>     >
>     >
>     > On 7/4/06, *Maryam Moazeni* <mmoazeni@gmail.com
>     <ma...@gmail.com>
>     > <mailto:mmoazeni@gmail.com <ma...@gmail.com>>> wrote:
>     >
>     >     Hi Dennis,
>     >
>     >     That's what I wanted to make sure !!! Thanks.
>     >
>     >     Maryam
>     >
>     >
>     >     On 7/4/06, *Dennis Sosnoski* < dms@sosnoski.com
>     <ma...@sosnoski.com>
>     >     <mailto:dms@sosnoski.com <ma...@sosnoski.com>>> wrote:
>     >
>     >         Hi Maryam,
>     >
>     >         This isn't a valid case. The only way to get
>     complexContent from a
>     >         simpleType is by using extension (since restriction says
>     that
>     >         you're
>     >         only going to allow a subset of what the base type allows -
>     >         which means
>     >         that the restriction of a simpleType is always going to be
>     >         simpleContent). Just to be sure, I tried this in Oxygen:
>     >
>     >         <?xml version=" 1.0" encoding="UTF-8"?>
>     >         <schema xmlns=" http://www.w3.org/2001/XMLSchema"
>     >         targetNamespace="urn:a"
>     >         xmlns:tns="urn:a">
>     >         <simpleType name="x">
>     >            <restriction base="decimal">
>     >              <minExclusive value="0.0"/>
>     >              <maxExclusive value ="100.0 "/>
>     >            </restriction>
>     >         </simpleType>
>     >
>     >         <complexType name="y">
>     >            <complexContent>
>     >              <restriction base="tns:x">
>     >                <minExclusive value=" 1.0"/>
>     >              </restriction>
>     >            </complexContent>
>     >         </complexType>
>     >         </schema>
>     >
>     >         It gave the expected error:
>     >
>     >         SystemID: /usr/local/tools/oxygen6.2/Untitled1.xsd
>     >         Location: 12:33
>     >         Description: E src-ct.1: Complex Type Definition
>     >         Representation Error
>     >         for type 'y'.  When <complexContent> is used, the base type
>     >         must be a
>     >         complexType. 'x' is a simpleType.
>     >         URL: http://www.w3.org/TR/xmlschema-1/#src-ct
>     >
>     >         - Dennis
>     >
>     >         Dennis M. Sosnoski
>     >         SOA, Web Services, and XML
>     >         Training and Consulting
>     >         http://www.sosnoski.com <http://www.sosnoski.com/
>     <http://www.sosnoski.com/>> -
>     >         http://www.sosnoski.co.nz <http://www.sosnoski.co.nz/>
>     >         Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
>     >
>     >
>     >
>     >         Maryam Moazeni wrote:
>     >         > Hi Ajith,
>     >         >
>     >         > actually I meant something else, I think what u mentioned
>     >         here is a
>     >         > SimpleTypeRestriction which I think is handeled in
>     >         > processSimpleSchemaType(...), I'm not sure though. Please
>     >         correct me
>     >         > if I'm wrong.
>     >         >
>     >         > But what I asked is the case of Complex Content when:
>     >         >
>     >         > *restriction.getBaseTypeName() instanceof
>     XmlSchemaSimpleType*
>     >         >
>     >         > For example:
>     >         >
>     >         > <simpleType name="x">
>     >         >       <restriction base="number">
>     >         >            <minExlusive value="0.0"/>
>     >         >            <maxExlusive value =" 100.0"/>
>     >         >       </restriction>
>     >         > </simpleType>
>     >         >
>     >         > <complexType name="y">
>     >         >     <complexContent>
>     >         >        *<restriction base="tns:x">*
>     >         > *          ....*
>     >         > *       *</restriction>
>     >         >      </complexContent>
>     >         > </complexType>
>     >         >
>     >         > I'd like to know what will happen in this case.
>     >         >
>     >         > Thanks,
>     >         > Maryam
>     >         >
>     >         >
>     >         > On 7/4/06, *Ajith Ranabahu* < ajith.ranabahu@gmail.com
>     <ma...@gmail.com>
>     >         <mailto:ajith.ranabahu@gmail.com
>     <ma...@gmail.com>>
>     >         > <mailto: ajith.ranabahu@gmail.com
>     <ma...@gmail.com>
>     >         <mailto:ajith.ranabahu@gmail.com
>     <ma...@gmail.com>>>> wrote:
>     >         >
>     >         >     Hi Maryam,
>     >         >     What I thought as appropriate for the simple type
>     is to
>     >         wrap the
>     >         >     necessary type in class and build the restriction
>     logic
>     >         into that
>     >         >     class.
>     >         >     For example think of a restriction based on xs:string
>     >         with a pattern
>     >         >     like the following
>     >         >
>     >         >     <xs:simpleType name="myType">
>     >         >            <xs:restriction base="xs:string">
>     >         >                     <xs:pattern value="\d"/>
>     >         >            </xs:restriction>
>     >         >     </xs:simpleType>
>     >         >
>     >         >     for this I suggest we generate a class MyType that
>     wraps a
>     >         >     java.lang.string. For the setter we can inserts a
>     reg exp
>     >         based
>     >         >     checker that throws an exception (??) for a wrong
>     value .
>     >         How does
>     >         >     that sound :)
>     >         >
>     >         >
>     >         >     Ajith
>     >         >
>     >         >     On 7/4/06, Maryam Moazeni <mmoazeni@gmail.com
>     <ma...@gmail.com>
>     >         <mailto: mmoazeni@gmail.com <ma...@gmail.com>>
>     >         >     <mailto: mmoazeni@gmail.com
>     <ma...@gmail.com> <mailto:mmoazeni@gmail.com
>     <ma...@gmail.com>>>>
>     >         wrote:
>     >         >     >
>     >         >     > Hi all,
>     >         >     >
>     >         >     > Regarding the complex content restriction:
>     >         >     >
>     >         >     > In the case that the restriction base type is a
>     complex
>     >         type,
>     >         >     the derived
>     >         >     > class overrides the getter and setter
>     corresponding to
>     >         >     restricted elements,
>     >         >     > but how about when the restriction base type is a
>     >         simple type?
>     >         >     simple types
>     >         >     > doesn't have elements !!
>     >         >     >
>     >         >     > in the current implementation for the extension of a
>     >         simple
>     >         >     type, the
>     >         >     > derived class extends "
>     org.apache.axiom.om.OMElement "
>     >         and its
>     >         >     elements are
>     >         >     > added to the class.
>     >         >     > but seems there's a different story for
>     restriction.
>     >         >     >
>     >         >     > Any Thoughts?
>     >         >     >
>     >         >     > Thanks,
>     >         >     >
>     >         >     > Maryam
>     >         >     >
>     >         >     >
>     >         >     >
>     >         >     > >
>     >         >     > >
>     >         >     > >
>     >         >     > >
>     >         >     > >
>     >         >     > > Hi Ajith,
>     >         >     > >
>     >         >     > >
>     >         >     > > Thanks for sharing your thoughts,
>     >         >     > >
>     >         >     > > For (1), (2) I was thinking of what you mentioned.
>     >         So, you say we
>     >         >     > shouldn't have the
>     >         >     > > real Java inheritance here because of the
>     existence of
>     >         >     primitive types,
>     >         >     > right?
>     >         >     > >
>     >         >     > >
>     >         >     > > Well, I have already started testing some simple
>     >         schemas with the
>     >         >     > XMLBeans. That seems to be the only source for me :)
>     >         >     > >
>     >         >     > > Thanks,
>     >         >     > >
>     >         >     > >
>     >         >     > > Maryam
>     >         >     > >
>     >         >     > >
>     >         >     > >
>     >         >     > >
>     >         >     > > On 6/22/06, Ajith Ranabahu <
>     ajith.ranabahu@gmail.com <ma...@gmail.com>
>     >         <mailto:ajith.ranabahu@gmail.com
>     <ma...@gmail.com>>
>     >         >     <mailto:ajith.ranabahu@gmail.com
>     <ma...@gmail.com>
>     >         <mailto:ajith.ranabahu@gmail.com
>     <ma...@gmail.com>>> > wrote:
>     >         >     > >
>     >         >     > > > Hi Maryam,
>     >         >     > > > I've had the thoughts for the supporting of
>     simple
>     >         content
>     >         >     extension
>     >         >     > > > and restriction and complex content
>     restriction (We
>     >         already
>     >         >     support
>     >         >     > > > complex content extension partially)
>     >         >     > > >
>     >         >     > > > 1. simple content extension
>     >         >     > > > This should generate a seperate class that
>     contains
>     >         the base
>     >         >     type as
>     >         >     > > > a field. for the variations, there would
>     be  other
>     >         fields
>     >         >     generated
>     >         >     > > > into the class (say in the case of attributes).
>     >         Note that
>     >         >     extending
>     >         >     > > > the classes would not work since there can
>     be java
>     >         >     primitives (like
>     >         >     > > > int and boolean) and even if mapped to a
>     class the
>     >         class may
>     >         >     not be
>     >         >     > > > extensible (like the java.lang.String which
>     is final)
>     >         >     > > >
>     >         >     > > > 2.  simple content restriction
>     >         >     > > > This should be the same as the extension
>     case but
>     >         now it
>     >         >     would have
>     >         >     > > > conditions generated into the the setter
>     method of
>     >         the base
>     >         >     field. Say
>     >         >     > > > in the case of enums there should be a list of
>     >         constants and the
>     >         >     > > > constants should be checked against the
>     input value
>     >         when
>     >         >     setting the
>     >         >     > > > value. Similar check can be done for the regular
>     >         expressions.
>     >         >     > > >
>     >         >     > > > 3. Complex content restriction
>     >         >     > > >   Hmm... this is somewhat tricky. What I see is
>     >         that we can
>     >         >     extend
>     >         >     > > > the generated class just like for extension but
>     >         overrride
>     >         >     the setters
>     >         >     > > > depending on the restriction.
>     >         >     > > >
>     >         >     > > > One thing you can do is to see what XMLbeans
>     does
>     >         for this.
>     >         >     Only thing
>     >         >     > > > is they generate classes all over the place
>     (:)) and it
>     >         >     might be a bit
>     >         >     > > > hard to figure out what is what :)
>     >         >     > > >
>     >         >     > > > Others please add your thoughts into this.
>     >         >     > > >
>     >         >     > > > Ajith
>     >         >     > > >
>     >         >     > > > On 6/21/06, Maryam Moazeni <
>     mmoazeni@gmail.com <ma...@gmail.com>
>     >         <mailto:mmoazeni@gmail.com <ma...@gmail.com>>
>     >         >     <mailto: mmoazeni@gmail.com
>     <ma...@gmail.com> <mailto:mmoazeni@gmail.com
>     <ma...@gmail.com>>>>
>     >         wrote:
>     >         >     > > > >
>     >         >     > > > >
>     >         >     > > > > Hi All,
>     >         >     > > > >
>     >         >     > > > > I'm doing a project for improving ADB for
>     Google
>     >         Summer of
>     >         >     Code,
>     >         >     > > > > At this point, I'm trying to implement the
>     >         >     > > > >
>     >         >     > > > > Simple Content Restriction and Extension
>     >         >     > > > > Complex Content Restriction and Extension
>     >         >     > > > > I'd like to receive sugestions from Axis2
>     >         Developers for
>     >         >     implementing
>     >         >     > these
>     >         >     > > > > features.
>     >         >     > > > > Any suggestions?
>     >         >     > > > >
>     >         >     > > > > Thanks,
>     >         >     > > > >
>     >         >     > > > >
>     >         >     > > > > Maryam Moazeni
>     >         >     > > >
>     >         >     > > >
>     >         >     > > > --
>     >         >     > > > Ajith Ranabahu
>     >         >     > > >
>     >         >     > > >
>     >         >     >
>     >         >
>     >        
>     ---------------------------------------------------------------------
>     >
>     >         >     > > > To unsubscribe, e-mail:
>     >         >     > axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     >         <mailto:axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>>
>     >         >     <mailto: axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     >         <mailto:axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>> >
>     >         >     > > > For additional commands, e-mail:
>     >         axis-dev-help@ws.apache.org
>     <ma...@ws.apache.org>
>     <mailto:axis-dev-help@ws.apache.org
>     <ma...@ws.apache.org>>
>     >         >     <mailto: axis-dev-help@ws.apache.org
>     <ma...@ws.apache.org>
>     >         <mailto:axis-dev-help@ws.apache.org
>     <ma...@ws.apache.org>>>
>     >         >     > > >
>     >         >     > > >
>     >         >     > >
>     >         >     > >
>     >         >     > >
>     >         >     >
>     >         >     >
>     >         >
>     >         >
>     >         >     --
>     >         >     Ajith Ranabahu
>     >         >
>     >         >
>     >        
>     ---------------------------------------------------------------------
>     >
>     >         >     To unsubscribe, e-mail:
>     >         axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     >         <mailto: axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>>
>     >         >     <mailto: axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     >         <mailto: axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>>>
>     >         >     For additional commands, e-mail:
>     >         axis-dev-help@ws.apache.org
>     <ma...@ws.apache.org> <mailto:
>     axis-dev-help@ws.apache.org <ma...@ws.apache.org>>
>     >         >     <mailto:axis-dev-help@ws.apache.org
>     <ma...@ws.apache.org>
>     >         <mailto: axis-dev-help@ws.apache.org
>     <ma...@ws.apache.org>>>
>     >         >
>     >         >
>     >
>     >        
>     ---------------------------------------------------------------------
>     >         To unsubscribe, e-mail:
>     axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     >         <mailto:axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>>
>     >         For additional commands, e-mail:
>     axis-dev-help@ws.apache.org <ma...@ws.apache.org>
>     >         <mailto:axis-dev-help@ws.apache.org
>     <ma...@ws.apache.org>>
>     >
>     >
>     >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     For additional commands, e-mail: axis-dev-help@ws.apache.org
>     <ma...@ws.apache.org>
>
>

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


Re: [axis2] Google SoC: ADB Project

Posted by Maryam Moazeni <mm...@gmail.com>.
Hi Dennis,

Thanks for the reply.
so your saying that types can be replaced by subtypes. For instance, xs:int
can be replaced by xs:int that is restricted between 0 and 100, right?

Also what about *attributes*, a restricted type could have less attributes
right? How a restricted type can change taking attributes into
consideration?

Thanks,
Maryam


On 7/9/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>
> Hi Maryam,
>
> Sounds about right, except that for (4) any element can be given a more
> specific type than in the base type definition (so an element typed as
> xs:string could instead be made xs:token, for instance), and for (5) an
> xs:any with maxOccurs > 1 could be replaced by multiple elements (or
> elements and a new xs:any).
>
> - Dennis
>
> Dennis M. Sosnoski
> SOA, Web Services, and XML
> Training and Consulting
> http://www.sosnoski.com - http://www.sosnoski.co.nz
> Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
>
>
>
> Maryam Moazeni wrote:
> >
> > Hi All,
> >
> > Regarding the implementation of the support for complex content
> > restriction:
> > I need to know in what cases an element could be restricted. I have
> > some observations, but I'd like to see if any one can add more to this.
> >
> > 1) Removal of an optional element.
> > 2) Reducing the "maxOccurs".
> > 3) Increasing the "minOccurs".
> > 4) Giving an element a specific type, in the case the element
> > has "anyType" as its type
> >     in the base type.
> > 5) In the case we have "any" in the base type, and we restrict the
> > elements by attributes
> >     of "any" such as "minOccurs" and "maxOccurs".
> >
> > Please correct me if I'm wrong and add your opinions.
> >
> > For implementing this I thought I should check all the elements listed
> > in the restricted type with elements of the base type for the named
> > conditions, if any of them differs, the element goes to the list of
> > restricted elements.
> >
> > Also, I thought with any approach that I choose, I have to edit the
> > DOM tree created from populating the parent meta info. But, it seems the
> >
> > Element root = model.getDocumentElement();
> >
> > return null when I'm trying to access the model's root element.
> >
> > In my approach, I thought maybe I can add "restricted" node to the
> > root node, per restricted elements and also edit the "property" nodes
> > according to the restricted elements to make sure that they're not
> > marked as "isInherited" or maybe we can remove them from the tree.
> >
> > Also I need to know what will happen in the case, base type is of type
> > "anyType"?
> >
> > I would appreciate if you share your thoughts with me.
> >
> > Thanks,
> > Maryam
> >
> >
> > On 7/4/06, *Maryam Moazeni* <mmoazeni@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> >     Hi Dennis,
> >
> >     That's what I wanted to make sure !!! Thanks.
> >
> >     Maryam
> >
> >
> >     On 7/4/06, *Dennis Sosnoski* <dms@sosnoski.com
> >     <ma...@sosnoski.com>> wrote:
> >
> >         Hi Maryam,
> >
> >         This isn't a valid case. The only way to get complexContent from
> a
> >         simpleType is by using extension (since restriction says that
> >         you're
> >         only going to allow a subset of what the base type allows -
> >         which means
> >         that the restriction of a simpleType is always going to be
> >         simpleContent). Just to be sure, I tried this in Oxygen:
> >
> >         <?xml version=" 1.0" encoding="UTF-8"?>
> >         <schema xmlns="http://www.w3.org/2001/XMLSchema"
> >         targetNamespace="urn:a"
> >         xmlns:tns="urn:a">
> >         <simpleType name="x">
> >            <restriction base="decimal">
> >              <minExclusive value="0.0"/>
> >              <maxExclusive value ="100.0 "/>
> >            </restriction>
> >         </simpleType>
> >
> >         <complexType name="y">
> >            <complexContent>
> >              <restriction base="tns:x">
> >                <minExclusive value=" 1.0"/>
> >              </restriction>
> >            </complexContent>
> >         </complexType>
> >         </schema>
> >
> >         It gave the expected error:
> >
> >         SystemID: /usr/local/tools/oxygen6.2/Untitled1.xsd
> >         Location: 12:33
> >         Description: E src-ct.1: Complex Type Definition
> >         Representation Error
> >         for type 'y'.  When <complexContent> is used, the base type
> >         must be a
> >         complexType. 'x' is a simpleType.
> >         URL: http://www.w3.org/TR/xmlschema-1/#src-ct
> >
> >         - Dennis
> >
> >         Dennis M. Sosnoski
> >         SOA, Web Services, and XML
> >         Training and Consulting
> >         http://www.sosnoski.com <http://www.sosnoski.com/> -
> >         http://www.sosnoski.co.nz <http://www.sosnoski.co.nz/>
> >         Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
> >
> >
> >
> >         Maryam Moazeni wrote:
> >         > Hi Ajith,
> >         >
> >         > actually I meant something else, I think what u mentioned
> >         here is a
> >         > SimpleTypeRestriction which I think is handeled in
> >         > processSimpleSchemaType(...), I'm not sure though. Please
> >         correct me
> >         > if I'm wrong.
> >         >
> >         > But what I asked is the case of Complex Content when:
> >         >
> >         > *restriction.getBaseTypeName() instanceof XmlSchemaSimpleType*
> >         >
> >         > For example:
> >         >
> >         > <simpleType name="x">
> >         >       <restriction base="number">
> >         >            <minExlusive value="0.0"/>
> >         >            <maxExlusive value =" 100.0"/>
> >         >       </restriction>
> >         > </simpleType>
> >         >
> >         > <complexType name="y">
> >         >     <complexContent>
> >         >        *<restriction base="tns:x">*
> >         > *          ....*
> >         > *       *</restriction>
> >         >      </complexContent>
> >         > </complexType>
> >         >
> >         > I'd like to know what will happen in this case.
> >         >
> >         > Thanks,
> >         > Maryam
> >         >
> >         >
> >         > On 7/4/06, *Ajith Ranabahu* < ajith.ranabahu@gmail.com
> >         <ma...@gmail.com>
> >         > <mailto: ajith.ranabahu@gmail.com
> >         <ma...@gmail.com>>> wrote:
> >         >
> >         >     Hi Maryam,
> >         >     What I thought as appropriate for the simple type is to
> >         wrap the
> >         >     necessary type in class and build the restriction logic
> >         into that
> >         >     class.
> >         >     For example think of a restriction based on xs:string
> >         with a pattern
> >         >     like the following
> >         >
> >         >     <xs:simpleType name="myType">
> >         >            <xs:restriction base="xs:string">
> >         >                     <xs:pattern value="\d"/>
> >         >            </xs:restriction>
> >         >     </xs:simpleType>
> >         >
> >         >     for this I suggest we generate a class MyType that wraps a
> >         >     java.lang.string. For the setter we can inserts a reg exp
> >         based
> >         >     checker that throws an exception (??) for a wrong value .
> >         How does
> >         >     that sound :)
> >         >
> >         >
> >         >     Ajith
> >         >
> >         >     On 7/4/06, Maryam Moazeni <mmoazeni@gmail.com
> >         <ma...@gmail.com>
> >         >     <mailto: mmoazeni@gmail.com <ma...@gmail.com>>>
> >         wrote:
> >         >     >
> >         >     > Hi all,
> >         >     >
> >         >     > Regarding the complex content restriction:
> >         >     >
> >         >     > In the case that the restriction base type is a complex
> >         type,
> >         >     the derived
> >         >     > class overrides the getter and setter corresponding to
> >         >     restricted elements,
> >         >     > but how about when the restriction base type is a
> >         simple type?
> >         >     simple types
> >         >     > doesn't have elements !!
> >         >     >
> >         >     > in the current implementation for the extension of a
> >         simple
> >         >     type, the
> >         >     > derived class extends " org.apache.axiom.om.OMElement "
> >         and its
> >         >     elements are
> >         >     > added to the class.
> >         >     > but seems there's a different story for restriction.
> >         >     >
> >         >     > Any Thoughts?
> >         >     >
> >         >     > Thanks,
> >         >     >
> >         >     > Maryam
> >         >     >
> >         >     >
> >         >     >
> >         >     > >
> >         >     > >
> >         >     > >
> >         >     > >
> >         >     > >
> >         >     > > Hi Ajith,
> >         >     > >
> >         >     > >
> >         >     > > Thanks for sharing your thoughts,
> >         >     > >
> >         >     > > For (1), (2) I was thinking of what you mentioned.
> >         So, you say we
> >         >     > shouldn't have the
> >         >     > > real Java inheritance here because of the existence of
> >         >     primitive types,
> >         >     > right?
> >         >     > >
> >         >     > >
> >         >     > > Well, I have already started testing some simple
> >         schemas with the
> >         >     > XMLBeans. That seems to be the only source for me :)
> >         >     > >
> >         >     > > Thanks,
> >         >     > >
> >         >     > >
> >         >     > > Maryam
> >         >     > >
> >         >     > >
> >         >     > >
> >         >     > >
> >         >     > > On 6/22/06, Ajith Ranabahu < ajith.ranabahu@gmail.com
> >         <ma...@gmail.com>
> >         >     <mailto:ajith.ranabahu@gmail.com
> >         <ma...@gmail.com>> > wrote:
> >         >     > >
> >         >     > > > Hi Maryam,
> >         >     > > > I've had the thoughts for the supporting of simple
> >         content
> >         >     extension
> >         >     > > > and restriction and complex content restriction (We
> >         already
> >         >     support
> >         >     > > > complex content extension partially)
> >         >     > > >
> >         >     > > > 1. simple content extension
> >         >     > > > This should generate a seperate class that contains
> >         the base
> >         >     type as
> >         >     > > > a field. for the variations, there would be  other
> >         fields
> >         >     generated
> >         >     > > > into the class (say in the case of attributes).
> >         Note that
> >         >     extending
> >         >     > > > the classes would not work since there can be java
> >         >     primitives (like
> >         >     > > > int and boolean) and even if mapped to a class the
> >         class may
> >         >     not be
> >         >     > > > extensible (like the java.lang.String which is
> final)
> >         >     > > >
> >         >     > > > 2.  simple content restriction
> >         >     > > > This should be the same as the extension case but
> >         now it
> >         >     would have
> >         >     > > > conditions generated into the the setter method of
> >         the base
> >         >     field. Say
> >         >     > > > in the case of enums there should be a list of
> >         constants and the
> >         >     > > > constants should be checked against the input value
> >         when
> >         >     setting the
> >         >     > > > value. Similar check can be done for the regular
> >         expressions.
> >         >     > > >
> >         >     > > > 3. Complex content restriction
> >         >     > > >   Hmm... this is somewhat tricky. What I see is
> >         that we can
> >         >     extend
> >         >     > > > the generated class just like for extension but
> >         overrride
> >         >     the setters
> >         >     > > > depending on the restriction.
> >         >     > > >
> >         >     > > > One thing you can do is to see what XMLbeans does
> >         for this.
> >         >     Only thing
> >         >     > > > is they generate classes all over the place (:)) and
> it
> >         >     might be a bit
> >         >     > > > hard to figure out what is what :)
> >         >     > > >
> >         >     > > > Others please add your thoughts into this.
> >         >     > > >
> >         >     > > > Ajith
> >         >     > > >
> >         >     > > > On 6/21/06, Maryam Moazeni < mmoazeni@gmail.com
> >         <ma...@gmail.com>
> >         >     <mailto: mmoazeni@gmail.com <ma...@gmail.com>>>
> >         wrote:
> >         >     > > > >
> >         >     > > > >
> >         >     > > > > Hi All,
> >         >     > > > >
> >         >     > > > > I'm doing a project for improving ADB for Google
> >         Summer of
> >         >     Code,
> >         >     > > > > At this point, I'm trying to implement the
> >         >     > > > >
> >         >     > > > > Simple Content Restriction and Extension
> >         >     > > > > Complex Content Restriction and Extension
> >         >     > > > > I'd like to receive sugestions from Axis2
> >         Developers for
> >         >     implementing
> >         >     > these
> >         >     > > > > features.
> >         >     > > > > Any suggestions?
> >         >     > > > >
> >         >     > > > > Thanks,
> >         >     > > > >
> >         >     > > > >
> >         >     > > > > Maryam Moazeni
> >         >     > > >
> >         >     > > >
> >         >     > > > --
> >         >     > > > Ajith Ranabahu
> >         >     > > >
> >         >     > > >
> >         >     >
> >         >
> >
> ---------------------------------------------------------------------
> >
> >         >     > > > To unsubscribe, e-mail:
> >         >     > axis-dev-unsubscribe@ws.apache.org
> >         <ma...@ws.apache.org>
> >         >     <mailto: axis-dev-unsubscribe@ws.apache.org
> >         <ma...@ws.apache.org> >
> >         >     > > > For additional commands, e-mail:
> >         axis-dev-help@ws.apache.org <ma...@ws.apache.org>
> >         >     <mailto: axis-dev-help@ws.apache.org
> >         <ma...@ws.apache.org>>
> >         >     > > >
> >         >     > > >
> >         >     > >
> >         >     > >
> >         >     > >
> >         >     >
> >         >     >
> >         >
> >         >
> >         >     --
> >         >     Ajith Ranabahu
> >         >
> >         >
> >
> ---------------------------------------------------------------------
> >
> >         >     To unsubscribe, e-mail:
> >         axis-dev-unsubscribe@ws.apache.org
> >         <ma...@ws.apache.org>
> >         >     <mailto: axis-dev-unsubscribe@ws.apache.org
> >         <ma...@ws.apache.org>>
> >         >     For additional commands, e-mail:
> >         axis-dev-help@ws.apache.org <ma...@ws.apache.org>
> >         >     <mailto:axis-dev-help@ws.apache.org
> >         <ma...@ws.apache.org>>
> >         >
> >         >
> >
> >
> ---------------------------------------------------------------------
> >         To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >         <ma...@ws.apache.org>
> >         For additional commands, e-mail: axis-dev-help@ws.apache.org
> >         <ma...@ws.apache.org>
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Re: [axis2] Google SoC: ADB Project

Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Maryam,

Sounds about right, except that for (4) any element can be given a more 
specific type than in the base type definition (so an element typed as 
xs:string could instead be made xs:token, for instance), and for (5) an 
xs:any with maxOccurs > 1 could be replaced by multiple elements (or 
elements and a new xs:any).

  - Dennis

Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117



Maryam Moazeni wrote:
>  
> Hi All,
>  
> Regarding the implementation of the support for complex content 
> restriction:
> I need to know in what cases an element could be restricted. I have 
> some observations, but I'd like to see if any one can add more to this.
>  
> 1) Removal of an optional element.
> 2) Reducing the "maxOccurs".
> 3) Increasing the "minOccurs".
> 4) Giving an element a specific type, in the case the element 
> has "anyType" as its type
>     in the base type.
> 5) In the case we have "any" in the base type, and we restrict the 
> elements by attributes
>     of "any" such as "minOccurs" and "maxOccurs".
>  
> Please correct me if I'm wrong and add your opinions.
>  
> For implementing this I thought I should check all the elements listed 
> in the restricted type with elements of the base type for the named 
> conditions, if any of them differs, the element goes to the list of 
> restricted elements.
>  
> Also, I thought with any approach that I choose, I have to edit the 
> DOM tree created from populating the parent meta info. But, it seems the 
>  
> Element root = model.getDocumentElement(); 
>  
> return null when I'm trying to access the model's root element.
>  
> In my approach, I thought maybe I can add "restricted" node to the 
> root node, per restricted elements and also edit the "property" nodes 
> according to the restricted elements to make sure that they're not 
> marked as "isInherited" or maybe we can remove them from the tree.
>  
> Also I need to know what will happen in the case, base type is of type 
> "anyType"?
>  
> I would appreciate if you share your thoughts with me.
>  
> Thanks,
> Maryam
>
>  
> On 7/4/06, *Maryam Moazeni* <mmoazeni@gmail.com 
> <ma...@gmail.com>> wrote:
>
>     Hi Dennis,
>      
>     That's what I wanted to make sure !!! Thanks.
>      
>     Maryam
>
>      
>     On 7/4/06, *Dennis Sosnoski* <dms@sosnoski.com
>     <ma...@sosnoski.com>> wrote:
>
>         Hi Maryam,
>
>         This isn't a valid case. The only way to get complexContent from a
>         simpleType is by using extension (since restriction says that
>         you're
>         only going to allow a subset of what the base type allows -
>         which means
>         that the restriction of a simpleType is always going to be
>         simpleContent). Just to be sure, I tried this in Oxygen:
>
>         <?xml version=" 1.0" encoding="UTF-8"?>
>         <schema xmlns="http://www.w3.org/2001/XMLSchema"
>         targetNamespace="urn:a"
>         xmlns:tns="urn:a">
>         <simpleType name="x">
>            <restriction base="decimal">
>              <minExclusive value="0.0"/>
>              <maxExclusive value ="100.0 "/>
>            </restriction>
>         </simpleType>
>
>         <complexType name="y">
>            <complexContent>
>              <restriction base="tns:x">
>                <minExclusive value=" 1.0"/>
>              </restriction>
>            </complexContent>
>         </complexType>
>         </schema>
>
>         It gave the expected error:
>
>         SystemID: /usr/local/tools/oxygen6.2/Untitled1.xsd
>         Location: 12:33
>         Description: E src-ct.1: Complex Type Definition
>         Representation Error
>         for type 'y'.  When <complexContent> is used, the base type
>         must be a
>         complexType. 'x' is a simpleType.
>         URL: http://www.w3.org/TR/xmlschema-1/#src-ct
>
>         - Dennis
>
>         Dennis M. Sosnoski
>         SOA, Web Services, and XML
>         Training and Consulting
>         http://www.sosnoski.com <http://www.sosnoski.com/> -
>         http://www.sosnoski.co.nz <http://www.sosnoski.co.nz/>
>         Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
>
>
>
>         Maryam Moazeni wrote:
>         > Hi Ajith,
>         >
>         > actually I meant something else, I think what u mentioned
>         here is a
>         > SimpleTypeRestriction which I think is handeled in
>         > processSimpleSchemaType(...), I'm not sure though. Please
>         correct me
>         > if I'm wrong.
>         >
>         > But what I asked is the case of Complex Content when:
>         >
>         > *restriction.getBaseTypeName() instanceof XmlSchemaSimpleType*
>         >
>         > For example:
>         >
>         > <simpleType name="x">
>         >       <restriction base="number">
>         >            <minExlusive value="0.0"/>
>         >            <maxExlusive value =" 100.0"/>
>         >       </restriction>
>         > </simpleType>
>         >
>         > <complexType name="y">
>         >     <complexContent>
>         >        *<restriction base="tns:x">*
>         > *          ....*
>         > *       *</restriction>
>         >      </complexContent>
>         > </complexType>
>         >
>         > I'd like to know what will happen in this case.
>         >
>         > Thanks,
>         > Maryam
>         >
>         >
>         > On 7/4/06, *Ajith Ranabahu* < ajith.ranabahu@gmail.com
>         <ma...@gmail.com>
>         > <mailto: ajith.ranabahu@gmail.com
>         <ma...@gmail.com>>> wrote:
>         >
>         >     Hi Maryam,
>         >     What I thought as appropriate for the simple type is to
>         wrap the
>         >     necessary type in class and build the restriction logic
>         into that
>         >     class.
>         >     For example think of a restriction based on xs:string
>         with a pattern
>         >     like the following
>         >
>         >     <xs:simpleType name="myType">
>         >            <xs:restriction base="xs:string">
>         >                     <xs:pattern value="\d"/>
>         >            </xs:restriction>
>         >     </xs:simpleType>
>         >
>         >     for this I suggest we generate a class MyType that wraps a
>         >     java.lang.string. For the setter we can inserts a reg exp
>         based
>         >     checker that throws an exception (??) for a wrong value .
>         How does
>         >     that sound :)
>         >
>         >
>         >     Ajith
>         >
>         >     On 7/4/06, Maryam Moazeni <mmoazeni@gmail.com
>         <ma...@gmail.com>
>         >     <mailto: mmoazeni@gmail.com <ma...@gmail.com>>>
>         wrote:
>         >     >
>         >     > Hi all,
>         >     >
>         >     > Regarding the complex content restriction:
>         >     >
>         >     > In the case that the restriction base type is a complex
>         type,
>         >     the derived
>         >     > class overrides the getter and setter corresponding to
>         >     restricted elements,
>         >     > but how about when the restriction base type is a
>         simple type?
>         >     simple types
>         >     > doesn't have elements !!
>         >     >
>         >     > in the current implementation for the extension of a
>         simple
>         >     type, the
>         >     > derived class extends " org.apache.axiom.om.OMElement "
>         and its
>         >     elements are
>         >     > added to the class.
>         >     > but seems there's a different story for restriction.
>         >     >
>         >     > Any Thoughts?
>         >     >
>         >     > Thanks,
>         >     >
>         >     > Maryam
>         >     >
>         >     >
>         >     >
>         >     > >
>         >     > >
>         >     > >
>         >     > >
>         >     > >
>         >     > > Hi Ajith,
>         >     > >
>         >     > >
>         >     > > Thanks for sharing your thoughts,
>         >     > >
>         >     > > For (1), (2) I was thinking of what you mentioned.
>         So, you say we
>         >     > shouldn't have the
>         >     > > real Java inheritance here because of the existence of
>         >     primitive types,
>         >     > right?
>         >     > >
>         >     > >
>         >     > > Well, I have already started testing some simple
>         schemas with the
>         >     > XMLBeans. That seems to be the only source for me :)
>         >     > >
>         >     > > Thanks,
>         >     > >
>         >     > >
>         >     > > Maryam
>         >     > >
>         >     > >
>         >     > >
>         >     > >
>         >     > > On 6/22/06, Ajith Ranabahu < ajith.ranabahu@gmail.com
>         <ma...@gmail.com>
>         >     <mailto:ajith.ranabahu@gmail.com
>         <ma...@gmail.com>> > wrote:
>         >     > >
>         >     > > > Hi Maryam,
>         >     > > > I've had the thoughts for the supporting of simple
>         content
>         >     extension
>         >     > > > and restriction and complex content restriction (We
>         already
>         >     support
>         >     > > > complex content extension partially)
>         >     > > >
>         >     > > > 1. simple content extension
>         >     > > > This should generate a seperate class that contains
>         the base
>         >     type as
>         >     > > > a field. for the variations, there would be  other
>         fields
>         >     generated
>         >     > > > into the class (say in the case of attributes).
>         Note that
>         >     extending
>         >     > > > the classes would not work since there can be java
>         >     primitives (like
>         >     > > > int and boolean) and even if mapped to a class the
>         class may
>         >     not be
>         >     > > > extensible (like the java.lang.String which is final)
>         >     > > >
>         >     > > > 2.  simple content restriction
>         >     > > > This should be the same as the extension case but
>         now it
>         >     would have
>         >     > > > conditions generated into the the setter method of
>         the base
>         >     field. Say
>         >     > > > in the case of enums there should be a list of
>         constants and the
>         >     > > > constants should be checked against the input value
>         when
>         >     setting the
>         >     > > > value. Similar check can be done for the regular
>         expressions.
>         >     > > >
>         >     > > > 3. Complex content restriction
>         >     > > >   Hmm... this is somewhat tricky. What I see is
>         that we can
>         >     extend
>         >     > > > the generated class just like for extension but
>         overrride
>         >     the setters
>         >     > > > depending on the restriction.
>         >     > > >
>         >     > > > One thing you can do is to see what XMLbeans does
>         for this.
>         >     Only thing
>         >     > > > is they generate classes all over the place (:)) and it
>         >     might be a bit
>         >     > > > hard to figure out what is what :)
>         >     > > >
>         >     > > > Others please add your thoughts into this.
>         >     > > >
>         >     > > > Ajith
>         >     > > >
>         >     > > > On 6/21/06, Maryam Moazeni < mmoazeni@gmail.com
>         <ma...@gmail.com>
>         >     <mailto: mmoazeni@gmail.com <ma...@gmail.com>>>
>         wrote:
>         >     > > > >
>         >     > > > >
>         >     > > > > Hi All,
>         >     > > > >
>         >     > > > > I'm doing a project for improving ADB for Google
>         Summer of
>         >     Code,
>         >     > > > > At this point, I'm trying to implement the
>         >     > > > >
>         >     > > > > Simple Content Restriction and Extension
>         >     > > > > Complex Content Restriction and Extension
>         >     > > > > I'd like to receive sugestions from Axis2
>         Developers for
>         >     implementing
>         >     > these
>         >     > > > > features.
>         >     > > > > Any suggestions?
>         >     > > > >
>         >     > > > > Thanks,
>         >     > > > >
>         >     > > > >
>         >     > > > > Maryam Moazeni
>         >     > > >
>         >     > > >
>         >     > > > --
>         >     > > > Ajith Ranabahu
>         >     > > >
>         >     > > >
>         >     >
>         >    
>         ---------------------------------------------------------------------
>
>         >     > > > To unsubscribe, e-mail:
>         >     > axis-dev-unsubscribe@ws.apache.org
>         <ma...@ws.apache.org>
>         >     <mailto: axis-dev-unsubscribe@ws.apache.org
>         <ma...@ws.apache.org> >
>         >     > > > For additional commands, e-mail:
>         axis-dev-help@ws.apache.org <ma...@ws.apache.org>
>         >     <mailto: axis-dev-help@ws.apache.org
>         <ma...@ws.apache.org>>
>         >     > > >
>         >     > > >
>         >     > >
>         >     > >
>         >     > >
>         >     >
>         >     >
>         >
>         >
>         >     --
>         >     Ajith Ranabahu
>         >
>         >    
>         ---------------------------------------------------------------------
>
>         >     To unsubscribe, e-mail:
>         axis-dev-unsubscribe@ws.apache.org
>         <ma...@ws.apache.org>
>         >     <mailto: axis-dev-unsubscribe@ws.apache.org
>         <ma...@ws.apache.org>>
>         >     For additional commands, e-mail:
>         axis-dev-help@ws.apache.org <ma...@ws.apache.org>
>         >     <mailto:axis-dev-help@ws.apache.org
>         <ma...@ws.apache.org>>
>         >
>         >
>
>         ---------------------------------------------------------------------
>         To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>         <ma...@ws.apache.org>
>         For additional commands, e-mail: axis-dev-help@ws.apache.org
>         <ma...@ws.apache.org>
>
>
>

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


Re: [axis2] Google SoC: ADB Project

Posted by Maryam Moazeni <mm...@gmail.com>.
Hi All,

Regarding the implementation of the support for complex content restriction:
I need to know in what cases an element could be restricted. I have some
observations, but I'd like to see if any one can add more to this.

1) Removal of an optional element.
2) Reducing the "maxOccurs".
3) Increasing the "minOccurs".
4) Giving an element a specific type, in the case the element has "anyType"
as its type
    in the base type.
5) In the case we have "any" in the base type, and we restrict the elements
by attributes
    of "any" such as "minOccurs" and "maxOccurs".

Please correct me if I'm wrong and add your opinions.

For implementing this I thought I should check all the elements listed in
the restricted type with elements of the base type for the named conditions,
if any of them differs, the element goes to the list of restricted elements.

Also, I thought with any approach that I choose, I have to edit the DOM tree
created from populating the parent meta info. But, it seems the

Element root = model.getDocumentElement();

return null when I'm trying to access the model's root element.

In my approach, I thought maybe I can add "restricted" node to the root
node, per restricted elements and also edit the "property" nodes according
to the restricted elements to make sure that they're not marked as
"isInherited" or maybe we can remove them from the tree.

Also I need to know what will happen in the case, base type is of type
"anyType"?

I would appreciate if you share your thoughts with me.

Thanks,
Maryam


On 7/4/06, Maryam Moazeni <mm...@gmail.com> wrote:
>
>  Hi Dennis,
>
> That's what I wanted to make sure !!! Thanks.
>
> Maryam
>
>
>  On 7/4/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >
> > Hi Maryam,
> >
> > This isn't a valid case. The only way to get complexContent from a
> > simpleType is by using extension (since restriction says that you're
> > only going to allow a subset of what the base type allows - which means
> > that the restriction of a simpleType is always going to be
> > simpleContent). Just to be sure, I tried this in Oxygen:
> >
> > <?xml version=" 1.0" encoding="UTF-8"?>
> > <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:a"
> > xmlns:tns="urn:a">
> > <simpleType name="x">
> >    <restriction base="decimal">
> >      <minExclusive value="0.0"/>
> >      <maxExclusive value ="100.0"/>
> >    </restriction>
> > </simpleType>
> >
> > <complexType name="y">
> >    <complexContent>
> >      <restriction base="tns:x">
> >        <minExclusive value="1.0"/>
> >      </restriction>
> >    </complexContent>
> > </complexType>
> > </schema>
> >
> > It gave the expected error:
> >
> > SystemID: /usr/local/tools/oxygen6.2/Untitled1.xsd
> > Location: 12:33
> > Description: E src-ct.1: Complex Type Definition Representation Error
> > for type 'y'.  When <complexContent> is used, the base type must be a
> > complexType. 'x' is a simpleType.
> > URL: http://www.w3.org/TR/xmlschema-1/#src-ct
> >
> > - Dennis
> >
> > Dennis M. Sosnoski
> > SOA, Web Services, and XML
> > Training and Consulting
> > http://www.sosnoski.com - http://www.sosnoski.co.nz
> > Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
> >
> >
> >
> > Maryam Moazeni wrote:
> > > Hi Ajith,
> > >
> > > actually I meant something else, I think what u mentioned here is a
> > > SimpleTypeRestriction which I think is handeled in
> > > processSimpleSchemaType(...), I'm not sure though. Please correct me
> > > if I'm wrong.
> > >
> > > But what I asked is the case of Complex Content when:
> > >
> > > *restriction.getBaseTypeName() instanceof XmlSchemaSimpleType*
> > >
> > > For example:
> > >
> > > <simpleType name="x">
> > >       <restriction base="number">
> > >            <minExlusive value="0.0"/>
> > >            <maxExlusive value =" 100.0"/>
> > >       </restriction>
> > > </simpleType>
> > >
> > > <complexType name="y">
> > >     <complexContent>
> > >        *<restriction base="tns:x">*
> > > *          ....*
> > > *       *</restriction>
> > >      </complexContent>
> > > </complexType>
> > >
> > > I'd like to know what will happen in this case.
> > >
> > > Thanks,
> > > Maryam
> > >
> > >
> > > On 7/4/06, *Ajith Ranabahu* <ajith.ranabahu@gmail.com
> > > <mailto:ajith.ranabahu@gmail.com >> wrote:
> > >
> > >     Hi Maryam,
> > >     What I thought as appropriate for the simple type is to wrap the
> > >     necessary type in class and build the restriction logic into that
> > >     class.
> > >     For example think of a restriction based on xs:string with a
> > pattern
> > >     like the following
> > >
> > >     <xs:simpleType name="myType">
> > >            <xs:restriction base="xs:string">
> > >                     <xs:pattern value="\d"/>
> > >            </xs:restriction>
> > >     </xs:simpleType>
> > >
> > >     for this I suggest we generate a class MyType that wraps a
> > >     java.lang.string. For the setter we can inserts a reg exp based
> > >     checker that throws an exception (??) for a wrong value . How does
> > >     that sound :)
> > >
> > >
> > >     Ajith
> > >
> > >     On 7/4/06, Maryam Moazeni <mmoazeni@gmail.com
> > >     <ma...@gmail.com>> wrote:
> > >     >
> > >     > Hi all,
> > >     >
> > >     > Regarding the complex content restriction:
> > >     >
> > >     > In the case that the restriction base type is a complex type,
> > >     the derived
> > >     > class overrides the getter and setter corresponding to
> > >     restricted elements,
> > >     > but how about when the restriction base type is a simple type?
> > >     simple types
> > >     > doesn't have elements !!
> > >     >
> > >     > in the current implementation for the extension of a simple
> > >     type, the
> > >     > derived class extends " org.apache.axiom.om.OMElement" and its
> > >     elements are
> > >     > added to the class.
> > >     > but seems there's a different story for restriction.
> > >     >
> > >     > Any Thoughts?
> > >     >
> > >     > Thanks,
> > >     >
> > >     > Maryam
> > >     >
> > >     >
> > >     >
> > >     > >
> > >     > >
> > >     > >
> > >     > >
> > >     > >
> > >     > > Hi Ajith,
> > >     > >
> > >     > >
> > >     > > Thanks for sharing your thoughts,
> > >     > >
> > >     > > For (1), (2) I was thinking of what you mentioned. So, you say
> > we
> > >     > shouldn't have the
> > >     > > real Java inheritance here because of the existence of
> > >     primitive types,
> > >     > right?
> > >     > >
> > >     > >
> > >     > > Well, I have already started testing some simple schemas with
> > the
> > >     > XMLBeans. That seems to be the only source for me :)
> > >     > >
> > >     > > Thanks,
> > >     > >
> > >     > >
> > >     > > Maryam
> > >     > >
> > >     > >
> > >     > >
> > >     > >
> > >     > > On 6/22/06, Ajith Ranabahu < ajith.ranabahu@gmail.com
> > >     <ma...@gmail.com> > wrote:
> > >     > >
> > >     > > > Hi Maryam,
> > >     > > > I've had the thoughts for the supporting of simple content
> > >     extension
> > >     > > > and restriction and complex content restriction (We already
> > >     support
> > >     > > > complex content extension partially)
> > >     > > >
> > >     > > > 1. simple content extension
> > >     > > > This should generate a seperate class that contains the base
> > >     type as
> > >     > > > a field. for the variations, there would be  other fields
> > >     generated
> > >     > > > into the class (say in the case of attributes). Note that
> > >     extending
> > >     > > > the classes would not work since there can be java
> > >     primitives (like
> > >     > > > int and boolean) and even if mapped to a class the class may
> > >     not be
> > >     > > > extensible (like the java.lang.String which is final)
> > >     > > >
> > >     > > > 2.  simple content restriction
> > >     > > > This should be the same as the extension case but now it
> > >     would have
> > >     > > > conditions generated into the the setter method of the base
> > >     field. Say
> > >     > > > in the case of enums there should be a list of constants and
> > the
> > >     > > > constants should be checked against the input value when
> > >     setting the
> > >     > > > value. Similar check can be done for the regular
> > expressions.
> > >     > > >
> > >     > > > 3. Complex content restriction
> > >     > > >   Hmm... this is somewhat tricky. What I see is that we can
> > >     extend
> > >     > > > the generated class just like for extension but overrride
> > >     the setters
> > >     > > > depending on the restriction.
> > >     > > >
> > >     > > > One thing you can do is to see what XMLbeans does for this.
> > >     Only thing
> > >     > > > is they generate classes all over the place (:)) and it
> > >     might be a bit
> > >     > > > hard to figure out what is what :)
> > >     > > >
> > >     > > > Others please add your thoughts into this.
> > >     > > >
> > >     > > > Ajith
> > >     > > >
> > >     > > > On 6/21/06, Maryam Moazeni < mmoazeni@gmail.com
> > >     <mailto: mmoazeni@gmail.com>> wrote:
> > >     > > > >
> > >     > > > >
> > >     > > > > Hi All,
> > >     > > > >
> > >     > > > > I'm doing a project for improving ADB for Google Summer of
> >
> > >     Code,
> > >     > > > > At this point, I'm trying to implement the
> > >     > > > >
> > >     > > > > Simple Content Restriction and Extension
> > >     > > > > Complex Content Restriction and Extension
> > >     > > > > I'd like to receive sugestions from Axis2 Developers for
> > >     implementing
> > >     > these
> > >     > > > > features.
> > >     > > > > Any suggestions?
> > >     > > > >
> > >     > > > > Thanks,
> > >     > > > >
> > >     > > > >
> > >     > > > > Maryam Moazeni
> > >     > > >
> > >     > > >
> > >     > > > --
> > >     > > > Ajith Ranabahu
> > >     > > >
> > >     > > >
> > >     >
> > >
> > ---------------------------------------------------------------------
> > >     > > > To unsubscribe, e-mail:
> > >     > axis-dev-unsubscribe@ws.apache.org
> > >     <mailto: axis-dev-unsubscribe@ws.apache.org>
> > >     > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >     <mailto: axis-dev-help@ws.apache.org>
> > >     > > >
> > >     > > >
> > >     > >
> > >     > >
> > >     > >
> > >     >
> > >     >
> > >
> > >
> > >     --
> > >     Ajith Ranabahu
> > >
> > >
> > ---------------------------------------------------------------------
> > >     To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > >     <ma...@ws.apache.org>
> > >     For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >     <ma...@ws.apache.org>
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>

Re: [axis2] Google SoC: ADB Project

Posted by Maryam Moazeni <mm...@gmail.com>.
Hi Dennis,

That's what I wanted to make sure !!! Thanks.

Maryam


On 7/4/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>
> Hi Maryam,
>
> This isn't a valid case. The only way to get complexContent from a
> simpleType is by using extension (since restriction says that you're
> only going to allow a subset of what the base type allows - which means
> that the restriction of a simpleType is always going to be
> simpleContent). Just to be sure, I tried this in Oxygen:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:a"
> xmlns:tns="urn:a">
> <simpleType name="x">
>    <restriction base="decimal">
>      <minExclusive value="0.0"/>
>      <maxExclusive value ="100.0"/>
>    </restriction>
> </simpleType>
>
> <complexType name="y">
>    <complexContent>
>      <restriction base="tns:x">
>        <minExclusive value="1.0"/>
>      </restriction>
>    </complexContent>
> </complexType>
> </schema>
>
> It gave the expected error:
>
> SystemID: /usr/local/tools/oxygen6.2/Untitled1.xsd
> Location: 12:33
> Description: E src-ct.1: Complex Type Definition Representation Error
> for type 'y'.  When <complexContent> is used, the base type must be a
> complexType. 'x' is a simpleType.
> URL: http://www.w3.org/TR/xmlschema-1/#src-ct
>
> - Dennis
>
> Dennis M. Sosnoski
> SOA, Web Services, and XML
> Training and Consulting
> http://www.sosnoski.com - http://www.sosnoski.co.nz
> Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
>
>
>
> Maryam Moazeni wrote:
> > Hi Ajith,
> >
> > actually I meant something else, I think what u mentioned here is a
> > SimpleTypeRestriction which I think is handeled in
> > processSimpleSchemaType(...), I'm not sure though. Please correct me
> > if I'm wrong.
> >
> > But what I asked is the case of Complex Content when:
> >
> > *restriction.getBaseTypeName() instanceof XmlSchemaSimpleType*
> >
> > For example:
> >
> > <simpleType name="x">
> >       <restriction base="number">
> >            <minExlusive value="0.0"/>
> >            <maxExlusive value ="100.0"/>
> >       </restriction>
> > </simpleType>
> >
> > <complexType name="y">
> >     <complexContent>
> >        *<restriction base="tns:x">*
> > *          ....*
> > *       *</restriction>
> >      </complexContent>
> > </complexType>
> >
> > I'd like to know what will happen in this case.
> >
> > Thanks,
> > Maryam
> >
> >
> > On 7/4/06, *Ajith Ranabahu* <ajith.ranabahu@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> >     Hi Maryam,
> >     What I thought as appropriate for the simple type is to wrap the
> >     necessary type in class and build the restriction logic into that
> >     class.
> >     For example think of a restriction based on xs:string with a pattern
> >     like the following
> >
> >     <xs:simpleType name="myType">
> >            <xs:restriction base="xs:string">
> >                     <xs:pattern value="\d"/>
> >            </xs:restriction>
> >     </xs:simpleType>
> >
> >     for this I suggest we generate a class MyType that wraps a
> >     java.lang.string. For the setter we can inserts a reg exp based
> >     checker that throws an exception (??) for a wrong value . How does
> >     that sound :)
> >
> >
> >     Ajith
> >
> >     On 7/4/06, Maryam Moazeni <mmoazeni@gmail.com
> >     <ma...@gmail.com>> wrote:
> >     >
> >     > Hi all,
> >     >
> >     > Regarding the complex content restriction:
> >     >
> >     > In the case that the restriction base type is a complex type,
> >     the derived
> >     > class overrides the getter and setter corresponding to
> >     restricted elements,
> >     > but how about when the restriction base type is a simple type?
> >     simple types
> >     > doesn't have elements !!
> >     >
> >     > in the current implementation for the extension of a simple
> >     type, the
> >     > derived class extends " org.apache.axiom.om.OMElement" and its
> >     elements are
> >     > added to the class.
> >     > but seems there's a different story for restriction.
> >     >
> >     > Any Thoughts?
> >     >
> >     > Thanks,
> >     >
> >     > Maryam
> >     >
> >     >
> >     >
> >     > >
> >     > >
> >     > >
> >     > >
> >     > >
> >     > > Hi Ajith,
> >     > >
> >     > >
> >     > > Thanks for sharing your thoughts,
> >     > >
> >     > > For (1), (2) I was thinking of what you mentioned. So, you say
> we
> >     > shouldn't have the
> >     > > real Java inheritance here because of the existence of
> >     primitive types,
> >     > right?
> >     > >
> >     > >
> >     > > Well, I have already started testing some simple schemas with
> the
> >     > XMLBeans. That seems to be the only source for me :)
> >     > >
> >     > > Thanks,
> >     > >
> >     > >
> >     > > Maryam
> >     > >
> >     > >
> >     > >
> >     > >
> >     > > On 6/22/06, Ajith Ranabahu < ajith.ranabahu@gmail.com
> >     <ma...@gmail.com> > wrote:
> >     > >
> >     > > > Hi Maryam,
> >     > > > I've had the thoughts for the supporting of simple content
> >     extension
> >     > > > and restriction and complex content restriction (We already
> >     support
> >     > > > complex content extension partially)
> >     > > >
> >     > > > 1. simple content extension
> >     > > > This should generate a seperate class that contains the base
> >     type as
> >     > > > a field. for the variations, there would be  other fields
> >     generated
> >     > > > into the class (say in the case of attributes). Note that
> >     extending
> >     > > > the classes would not work since there can be java
> >     primitives (like
> >     > > > int and boolean) and even if mapped to a class the class may
> >     not be
> >     > > > extensible (like the java.lang.String which is final)
> >     > > >
> >     > > > 2.  simple content restriction
> >     > > > This should be the same as the extension case but now it
> >     would have
> >     > > > conditions generated into the the setter method of the base
> >     field. Say
> >     > > > in the case of enums there should be a list of constants and
> the
> >     > > > constants should be checked against the input value when
> >     setting the
> >     > > > value. Similar check can be done for the regular expressions.
> >     > > >
> >     > > > 3. Complex content restriction
> >     > > >   Hmm... this is somewhat tricky. What I see is that we can
> >     extend
> >     > > > the generated class just like for extension but overrride
> >     the setters
> >     > > > depending on the restriction.
> >     > > >
> >     > > > One thing you can do is to see what XMLbeans does for this.
> >     Only thing
> >     > > > is they generate classes all over the place (:)) and it
> >     might be a bit
> >     > > > hard to figure out what is what :)
> >     > > >
> >     > > > Others please add your thoughts into this.
> >     > > >
> >     > > > Ajith
> >     > > >
> >     > > > On 6/21/06, Maryam Moazeni < mmoazeni@gmail.com
> >     <ma...@gmail.com>> wrote:
> >     > > > >
> >     > > > >
> >     > > > > Hi All,
> >     > > > >
> >     > > > > I'm doing a project for improving ADB for Google Summer of
> >     Code,
> >     > > > > At this point, I'm trying to implement the
> >     > > > >
> >     > > > > Simple Content Restriction and Extension
> >     > > > > Complex Content Restriction and Extension
> >     > > > > I'd like to receive sugestions from Axis2 Developers for
> >     implementing
> >     > these
> >     > > > > features.
> >     > > > > Any suggestions?
> >     > > > >
> >     > > > > Thanks,
> >     > > > >
> >     > > > >
> >     > > > > Maryam Moazeni
> >     > > >
> >     > > >
> >     > > > --
> >     > > > Ajith Ranabahu
> >     > > >
> >     > > >
> >     >
> >
> ---------------------------------------------------------------------
> >     > > > To unsubscribe, e-mail:
> >     > axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>
> >     > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >     <ma...@ws.apache.org>
> >     > > >
> >     > > >
> >     > >
> >     > >
> >     > >
> >     >
> >     >
> >
> >
> >     --
> >     Ajith Ranabahu
> >
> >
> ---------------------------------------------------------------------
> >     To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>
> >     For additional commands, e-mail: axis-dev-help@ws.apache.org
> >     <ma...@ws.apache.org>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Re: [axis2] Google SoC: ADB Project

Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Maryam,

This isn't a valid case. The only way to get complexContent from a 
simpleType is by using extension (since restriction says that you're 
only going to allow a subset of what the base type allows - which means 
that the restriction of a simpleType is always going to be 
simpleContent). Just to be sure, I tried this in Oxygen:

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:a" 
xmlns:tns="urn:a">
  <simpleType name="x">
    <restriction base="decimal">
      <minExclusive value="0.0"/>
      <maxExclusive value ="100.0"/>
    </restriction>
  </simpleType>
 
  <complexType name="y">
    <complexContent>
      <restriction base="tns:x">
        <minExclusive value="1.0"/>
      </restriction>
    </complexContent>
  </complexType>
</schema>

It gave the expected error:

SystemID: /usr/local/tools/oxygen6.2/Untitled1.xsd
Location: 12:33
Description: E src-ct.1: Complex Type Definition Representation Error 
for type 'y'.  When <complexContent> is used, the base type must be a 
complexType. 'x' is a simpleType.
URL: http://www.w3.org/TR/xmlschema-1/#src-ct

  - Dennis

Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117



Maryam Moazeni wrote:
> Hi Ajith,
>  
> actually I meant something else, I think what u mentioned here is a 
> SimpleTypeRestriction which I think is handeled in 
> processSimpleSchemaType(...), I'm not sure though. Please correct me 
> if I'm wrong.
>  
> But what I asked is the case of Complex Content when:
>  
> *restriction.getBaseTypeName() instanceof XmlSchemaSimpleType*
>  
> For example:
>  
> <simpleType name="x">
>       <restriction base="number">
>            <minExlusive value="0.0"/>
>            <maxExlusive value ="100.0"/>
>       </restriction>
> </simpleType>
>  
> <complexType name="y">
>     <complexContent>
>        *<restriction base="tns:x">*
> *          ....*
> *       *</restriction>
>      </complexContent>
> </complexType>
>  
> I'd like to know what will happen in this case.
>  
> Thanks,
> Maryam
>
>  
> On 7/4/06, *Ajith Ranabahu* <ajith.ranabahu@gmail.com 
> <ma...@gmail.com>> wrote:
>
>     Hi Maryam,
>     What I thought as appropriate for the simple type is to wrap the
>     necessary type in class and build the restriction logic into that
>     class.
>     For example think of a restriction based on xs:string with a pattern
>     like the following
>
>     <xs:simpleType name="myType">
>            <xs:restriction base="xs:string">
>                     <xs:pattern value="\d"/>
>            </xs:restriction>
>     </xs:simpleType>
>
>     for this I suggest we generate a class MyType that wraps a
>     java.lang.string. For the setter we can inserts a reg exp based
>     checker that throws an exception (??) for a wrong value . How does
>     that sound :)
>
>
>     Ajith
>
>     On 7/4/06, Maryam Moazeni <mmoazeni@gmail.com
>     <ma...@gmail.com>> wrote:
>     >
>     > Hi all,
>     >
>     > Regarding the complex content restriction:
>     >
>     > In the case that the restriction base type is a complex type,
>     the derived
>     > class overrides the getter and setter corresponding to
>     restricted elements,
>     > but how about when the restriction base type is a simple type?
>     simple types
>     > doesn't have elements !!
>     >
>     > in the current implementation for the extension of a simple
>     type, the
>     > derived class extends " org.apache.axiom.om.OMElement" and its
>     elements are
>     > added to the class.
>     > but seems there's a different story for restriction.
>     >
>     > Any Thoughts?
>     >
>     > Thanks,
>     >
>     > Maryam
>     >
>     >
>     >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > > Hi Ajith,
>     > >
>     > >
>     > > Thanks for sharing your thoughts,
>     > >
>     > > For (1), (2) I was thinking of what you mentioned. So, you say we
>     > shouldn't have the
>     > > real Java inheritance here because of the existence of
>     primitive types,
>     > right?
>     > >
>     > >
>     > > Well, I have already started testing some simple schemas with the
>     > XMLBeans. That seems to be the only source for me :)
>     > >
>     > > Thanks,
>     > >
>     > >
>     > > Maryam
>     > >
>     > >
>     > >
>     > >
>     > > On 6/22/06, Ajith Ranabahu < ajith.ranabahu@gmail.com
>     <ma...@gmail.com> > wrote:
>     > >
>     > > > Hi Maryam,
>     > > > I've had the thoughts for the supporting of simple content
>     extension
>     > > > and restriction and complex content restriction (We already
>     support
>     > > > complex content extension partially)
>     > > >
>     > > > 1. simple content extension
>     > > > This should generate a seperate class that contains the base
>     type as
>     > > > a field. for the variations, there would be  other fields
>     generated
>     > > > into the class (say in the case of attributes). Note that
>     extending
>     > > > the classes would not work since there can be java
>     primitives (like
>     > > > int and boolean) and even if mapped to a class the class may
>     not be
>     > > > extensible (like the java.lang.String which is final)
>     > > >
>     > > > 2.  simple content restriction
>     > > > This should be the same as the extension case but now it
>     would have
>     > > > conditions generated into the the setter method of the base
>     field. Say
>     > > > in the case of enums there should be a list of constants and the
>     > > > constants should be checked against the input value when
>     setting the
>     > > > value. Similar check can be done for the regular expressions.
>     > > >
>     > > > 3. Complex content restriction
>     > > >   Hmm... this is somewhat tricky. What I see is that we can
>     extend
>     > > > the generated class just like for extension but overrride
>     the setters
>     > > > depending on the restriction.
>     > > >
>     > > > One thing you can do is to see what XMLbeans does for this.
>     Only thing
>     > > > is they generate classes all over the place (:)) and it
>     might be a bit
>     > > > hard to figure out what is what :)
>     > > >
>     > > > Others please add your thoughts into this.
>     > > >
>     > > > Ajith
>     > > >
>     > > > On 6/21/06, Maryam Moazeni < mmoazeni@gmail.com
>     <ma...@gmail.com>> wrote:
>     > > > >
>     > > > >
>     > > > > Hi All,
>     > > > >
>     > > > > I'm doing a project for improving ADB for Google Summer of
>     Code,
>     > > > > At this point, I'm trying to implement the
>     > > > >
>     > > > > Simple Content Restriction and Extension
>     > > > > Complex Content Restriction and Extension
>     > > > > I'd like to receive sugestions from Axis2 Developers for
>     implementing
>     > these
>     > > > > features.
>     > > > > Any suggestions?
>     > > > >
>     > > > > Thanks,
>     > > > >
>     > > > >
>     > > > > Maryam Moazeni
>     > > >
>     > > >
>     > > > --
>     > > > Ajith Ranabahu
>     > > >
>     > > >
>     >
>     ---------------------------------------------------------------------
>     > > > To unsubscribe, e-mail:
>     > axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
>     <ma...@ws.apache.org>
>     > > >
>     > > >
>     > >
>     > >
>     > >
>     >
>     >
>
>
>     --
>     Ajith Ranabahu
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     For additional commands, e-mail: axis-dev-help@ws.apache.org
>     <ma...@ws.apache.org>
>
>

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


Re: [axis2] Google SoC: ADB Project

Posted by Maryam Moazeni <mm...@gmail.com>.
Hi Ajith,

actually I meant something else, I think what u mentioned here is a
SimpleTypeRestriction which I think is handeled in
processSimpleSchemaType(...), I'm not sure though. Please correct me if I'm
wrong.

But what I asked is the case of Complex Content when:

*restriction.getBaseTypeName() instanceof XmlSchemaSimpleType*

For example:

<simpleType name="x">
      <restriction base="number">
           <minExlusive value="0.0"/>
           <maxExlusive value ="100.0"/>
      </restriction>
</simpleType>

<complexType name="y">
    <complexContent>
       *<restriction base="tns:x">*
*          ....*
*       *</restriction>
     </complexContent>
</complexType>

I'd like to know what will happen in this case.

Thanks,
Maryam


On 7/4/06, Ajith Ranabahu <aj...@gmail.com> wrote:
>
> Hi Maryam,
> What I thought as appropriate for the simple type is to wrap the
> necessary type in class and build the restriction logic into that
> class.
> For example think of a restriction based on xs:string with a pattern
> like the following
>
> <xs:simpleType name="myType">
>        <xs:restriction base="xs:string">
>                 <xs:pattern value="\d"/>
>        </xs:restriction>
> </xs:simpleType>
>
> for this I suggest we generate a class MyType that wraps a
> java.lang.string. For the setter we can inserts a reg exp based
> checker that throws an exception (??) for a wrong value . How does
> that sound :)
>
>
> Ajith
>
> On 7/4/06, Maryam Moazeni <mm...@gmail.com> wrote:
> >
> > Hi all,
> >
> > Regarding the complex content restriction:
> >
> > In the case that the restriction base type is a complex type, the
> derived
> > class overrides the getter and setter corresponding to restricted
> elements,
> > but how about when the restriction base type is a simple type? simple
> types
> > doesn't have elements !!
> >
> > in the current implementation for the extension of a simple type, the
> > derived class extends "org.apache.axiom.om.OMElement" and its elements
> are
> > added to the class.
> > but seems there's a different story for restriction.
> >
> > Any Thoughts?
> >
> > Thanks,
> >
> > Maryam
> >
> >
> >
> > >
> > >
> > >
> > >
> > >
> > > Hi Ajith,
> > >
> > >
> > > Thanks for sharing your thoughts,
> > >
> > > For (1), (2) I was thinking of what you mentioned. So, you say we
> > shouldn't have the
> > > real Java inheritance here because of the existence of primitive
> types,
> > right?
> > >
> > >
> > > Well, I have already started testing some simple schemas with the
> > XMLBeans. That seems to be the only source for me :)
> > >
> > > Thanks,
> > >
> > >
> > > Maryam
> > >
> > >
> > >
> > >
> > > On 6/22/06, Ajith Ranabahu < ajith.ranabahu@gmail.com > wrote:
> > >
> > > > Hi Maryam,
> > > > I've had the thoughts for the supporting of simple content extension
> > > > and restriction and complex content restriction (We already support
> > > > complex content extension partially)
> > > >
> > > > 1. simple content extension
> > > > This should generate a seperate class that contains the base type as
> > > > a field. for the variations, there would be  other fields generated
> > > > into the class (say in the case of attributes). Note that extending
> > > > the classes would not work since there can be java primitives (like
> > > > int and boolean) and even if mapped to a class the class may not be
> > > > extensible (like the java.lang.String which is final)
> > > >
> > > > 2.  simple content restriction
> > > > This should be the same as the extension case but now it would have
> > > > conditions generated into the the setter method of the base field.
> Say
> > > > in the case of enums there should be a list of constants and the
> > > > constants should be checked against the input value when setting the
> > > > value. Similar check can be done for the regular expressions.
> > > >
> > > > 3. Complex content restriction
> > > >   Hmm... this is somewhat tricky. What I see is that we can extend
> > > > the generated class just like for extension but overrride the
> setters
> > > > depending on the restriction.
> > > >
> > > > One thing you can do is to see what XMLbeans does for this. Only
> thing
> > > > is they generate classes all over the place (:)) and it might be a
> bit
> > > > hard to figure out what is what :)
> > > >
> > > > Others please add your thoughts into this.
> > > >
> > > > Ajith
> > > >
> > > > On 6/21/06, Maryam Moazeni < mmoazeni@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I'm doing a project for improving ADB for Google Summer of Code,
> > > > > At this point, I'm trying to implement the
> > > > >
> > > > > Simple Content Restriction and Extension
> > > > > Complex Content Restriction and Extension
> > > > > I'd like to receive sugestions from Axis2 Developers for
> implementing
> > these
> > > > > features.
> > > > > Any suggestions?
> > > > >
> > > > > Thanks,
> > > > >
> > > > >
> > > > > Maryam Moazeni
> > > >
> > > >
> > > > --
> > > > Ajith Ranabahu
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > axis-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>
> --
> Ajith Ranabahu
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Re: [axis2] Google SoC: ADB Project

Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Maryam,
What I thought as appropriate for the simple type is to wrap the
necessary type in class and build the restriction logic into that
class.
For example think of a restriction based on xs:string with a pattern
like the following

<xs:simpleType name="myType">
	<xs:restriction base="xs:string">
		 <xs:pattern value="\d"/>
	</xs:restriction>
</xs:simpleType>

for this I suggest we generate a class MyType that wraps a
java.lang.string. For the setter we can inserts a reg exp based
checker that throws an exception (??) for a wrong value . How does
that sound :)


Ajith

On 7/4/06, Maryam Moazeni <mm...@gmail.com> wrote:
>
> Hi all,
>
> Regarding the complex content restriction:
>
> In the case that the restriction base type is a complex type, the derived
> class overrides the getter and setter corresponding to restricted elements,
> but how about when the restriction base type is a simple type? simple types
> doesn't have elements !!
>
> in the current implementation for the extension of a simple type, the
> derived class extends "org.apache.axiom.om.OMElement" and its elements are
> added to the class.
> but seems there's a different story for restriction.
>
> Any Thoughts?
>
> Thanks,
>
> Maryam
>
>
>
> >
> >
> >
> >
> >
> > Hi Ajith,
> >
> >
> > Thanks for sharing your thoughts,
> >
> > For (1), (2) I was thinking of what you mentioned. So, you say we
> shouldn't have the
> > real Java inheritance here because of the existence of primitive types,
> right?
> >
> >
> > Well, I have already started testing some simple schemas with the
> XMLBeans. That seems to be the only source for me :)
> >
> > Thanks,
> >
> >
> > Maryam
> >
> >
> >
> >
> > On 6/22/06, Ajith Ranabahu < ajith.ranabahu@gmail.com > wrote:
> >
> > > Hi Maryam,
> > > I've had the thoughts for the supporting of simple content extension
> > > and restriction and complex content restriction (We already support
> > > complex content extension partially)
> > >
> > > 1. simple content extension
> > > This should generate a seperate class that contains the base type as
> > > a field. for the variations, there would be  other fields generated
> > > into the class (say in the case of attributes). Note that extending
> > > the classes would not work since there can be java primitives (like
> > > int and boolean) and even if mapped to a class the class may not be
> > > extensible (like the java.lang.String which is final)
> > >
> > > 2.  simple content restriction
> > > This should be the same as the extension case but now it would have
> > > conditions generated into the the setter method of the base field. Say
> > > in the case of enums there should be a list of constants and the
> > > constants should be checked against the input value when setting the
> > > value. Similar check can be done for the regular expressions.
> > >
> > > 3. Complex content restriction
> > >   Hmm... this is somewhat tricky. What I see is that we can extend
> > > the generated class just like for extension but overrride the setters
> > > depending on the restriction.
> > >
> > > One thing you can do is to see what XMLbeans does for this. Only thing
> > > is they generate classes all over the place (:)) and it might be a bit
> > > hard to figure out what is what :)
> > >
> > > Others please add your thoughts into this.
> > >
> > > Ajith
> > >
> > > On 6/21/06, Maryam Moazeni < mmoazeni@gmail.com> wrote:
> > > >
> > > >
> > > > Hi All,
> > > >
> > > > I'm doing a project for improving ADB for Google Summer of Code,
> > > > At this point, I'm trying to implement the
> > > >
> > > > Simple Content Restriction and Extension
> > > > Complex Content Restriction and Extension
> > > > I'd like to receive sugestions from Axis2 Developers for implementing
> these
> > > > features.
> > > > Any suggestions?
> > > >
> > > > Thanks,
> > > >
> > > >
> > > > Maryam Moazeni
> > >
> > >
> > > --
> > > Ajith Ranabahu
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
> >
>
>


-- 
Ajith Ranabahu

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