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]> 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] > 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]> 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]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
