Hi Dennis,
 
That's what I wanted to make sure !!! Thanks.
 
Maryam

 
On 7/4/06, Dennis Sosnoski <[EMAIL PROTECTED]> 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* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED] >> 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 <[EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>> 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 < [EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]> > 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 < [EMAIL PROTECTED]
>     <mailto: [EMAIL PROTECTED]>> 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:
>     > [EMAIL PROTECTED]
>     <mailto: [EMAIL PROTECTED]>
>     > > > For additional commands, e-mail: [EMAIL PROTECTED]
>     <mailto: [EMAIL PROTECTED]>
>     > > >
>     > > >
>     > >
>     > >
>     > >
>     >
>     >
>
>
>     --
>     Ajith Ranabahu
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>
>     For additional commands, e-mail: [EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to