axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maryam Moazeni" <mmoaz...@gmail.com>
Subject Re: [axis2] Google SoC: ADB Project
Date Sun, 09 Jul 2006 14:13:39 GMT
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> 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
> > <mailto:mmoazeni@gmail.com>> wrote:
> >
> >     Hi Dennis,
> >
> >     That's what I wanted to make sure !!! Thanks.
> >
> >     Maryam
> >
> >
> >     On 7/4/06, *Dennis Sosnoski* <dms@sosnoski.com
> >     <mailto:dms@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
> >         <mailto:ajith.ranabahu@gmail.com>
> >         > <mailto: 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
> >         <mailto:mmoazeni@gmail.com>
> >         >     <mailto: mmoazeni@gmail.com <mailto:mmoazeni@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
> >         <mailto:ajith.ranabahu@gmail.com>
> >         >     <mailto:ajith.ranabahu@gmail.com
> >         <mailto: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
> >         <mailto:mmoazeni@gmail.com>
> >         >     <mailto: 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>
> >         >     <mailto: 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>
> >         >     <mailto: 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
> >         <mailto:axis-dev-unsubscribe@ws.apache.org>
> >         >     <mailto: 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>
> >         >     <mailto:axis-dev-help@ws.apache.org
> >         <mailto:axis-dev-help@ws.apache.org>>
> >         >
> >         >
> >
> >
> ---------------------------------------------------------------------
> >         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>
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Mime
View raw message