Alberto, 
Thank you so much for your help (and patience).
I believe I can manage by myself from this point.

One last thing:
Since I want to keep the types in my application as an enum and not as
strings, I still need to translate the names I get from 
getPrimitiveType->getName() to an enum (similar to XSValue::DataType).
Are those the SchemaSymbols::fgDT_XXXXX strings. How come there are only
38 fgDT_ strings while the XSValue::DataType contains 44?
 
Also, I wanted to add, that the schema component is a great open source
tool and a very important part of Xerces, and I wish it was documented
and opened for the public the same way the parser is.
When I finish, I will try to submit a part of my code to serve as an
example for those who seek for the same solution as mine. Can I send it
to this list as an attachment?

Regards,
Ori.


-----Original Message-----
From: Alberto Massari [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 17, 2006 11:05 AM
To: [email protected]
Subject: RE: Parsing Schema Grammar - waiting for an answer

Hi Ori,

At 00.32 17/08/2006 +0200, Ori Doolman wrote:
>[...]
>So my questions are:
>1. The only way I see to get the primitive type (i.e., string, int,
>double etc) of a simple type is using its DatatypeValidator member.
>Is there any other way not using the DatatypeValidator object?

The two methods getName and getNamespace should tell you the name of 
the type (unless getAnonymous is true); if you are looking at a 
restriction you will have to walk the inheritance chain by examining 
the XSSimpleType returned by getPrimitiveType

>2. I still cannot find the way of getting the primitive types
>(recursively, after getting the inner elements) of a complex element.
>Can I get it somehow from the Particle?
>For example, for the following complex element
>
><xsd:element name="ServiceException"
>type="parlayx_common_xsd:ServiceException"/>
>    <xsd:complexType name="ServiceException">
>       <xsd:sequence>
>          <xsd:element name="messageId" type="xsd:int"/>
>          <xsd:element name="text" type="xsd:string"/>
>          <xsd:element name="variables" type="xsd:string" minOccurs="0"
>maxOccurs="unbounded"/>
>       </xsd:sequence>
>    </xsd:complexType>
>
>I would like to get 3 primitives:
>Int, string, string

The XSParticle returned by getParticle maps (in this case) the 
xs:sequence, so its method getTermType will return TERM_MODELGROUP, 
so you can call getModelGroupTerm that will return a XSModelGroup 
which will hav a getCompositor equal to COMPOSITOR_SEQUENCE.
Iterating over the XSParticleList returned by the 
XSModelGroup->getParticles you will find the particles for the 
xsd:element definition; in those cases the XSParticle will have a 
getTermType of TERM_ELEMENT and you will have to inspect the 
XSElementDeclaration returned by getElementTerm.

Alberto


>Thank you,
>Ori.
>
>
>
>
>-----Original Message-----
>From: Alberto Massari [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, August 16, 2006 5:54 PM
>To: [email protected]
>Subject: RE: Parsing Schema Grammar - waiting for an answer
>
>Hi Ori,
>
>At 18.14 16/08/2006 +0200, Ori Doolman wrote:
> >Alberto,
> >Currently, I have problems with both of your solutions:
> >
> >- When implementing the 1st solution using grammar->getElemDecl, it
> >appears that I cannot get the SchemaElementDecl object for elements
>that
> >are declared within an imported schema document (i.e., xsd:import)
>
>An imported schema has a different namespace; you should first get
>the Grammar object for that namespace before looking for an element.
>
> >- When implementing the 2nd solution using XSModel, I do get a valid
> >XSElementDeclaration, but I cannot get the SchemaElementDecl object
>from
> >my XSElementDeclaration, since it does not have a public getter
> >function.
>
>If you use XSModel, you cannot get a SchemaElementDecl; you can only
>traverse the XSModel object model (XSComplexTypeDefinition ->
>XSParticle and so on)
>
>
> >Any suggestions?
> >(I guess I can always use the pGrammar->getElemEnumerator() if there
is
> >no other elegant way)
> >
> >And another question:
> >If my element is looking like this:
> >   <xsd:element name="TimeMetrics"
> >type="parlayx_common_xsd:TimeMetrics"/>
> >    <xsd:simpleType name="TimeMetrics">
> >       <xsd:restriction base="xsd:string">
> >          <xsd:enumeration value="Millisecond"/>
> >          <xsd:enumeration value="Second"/>
> >          <xsd:enumeration value="Minute"/>
> >          <xsd:enumeration value="Hour"/>
> >          <xsd:enumeration value="Day"/>
> >          <xsd:enumeration value="Week"/>
> >          <xsd:enumeration value="Month"/>
> >          <xsd:enumeration value="Year"/>
> >       </xsd:restriction>
> >    </xsd:simpleType>
> >
> >Where (in the SchemaElementDecl object) can I find the enumeration
> >values data?
> >Actually, my question is more general: Where can I find all the
> >restrictions like minOccurs, maxOccurs etc?
>
>The enumeration values are in the DatatypeValidator class
>(SchemaElementDecl->getComplexTypeInfo()->getDatatypeValidator()->getEn
u
>mString());
>the minOccurs/maxOccurs are stored inside the ContentSpecNode
>returned by
>SchemaElementDecl->getComplexTypeInfo()->getContentSpec(). But if you
>really want to navigate a representation of the XMLSchema you loaded
>you should use the XSModel; as I have said, the SchemaElementDecl
>structure is optimized for validating the data, not for exposing its
>structure.
>
>Alberto
>
>
>
> >Thanks,
> >Ori.
> >
> >
> >-----Original Message-----
> >From: Alberto Massari [mailto:[EMAIL PROTECTED]
> >Sent: Wednesday, August 16, 2006 3:42 PM
> >To: [email protected]
> >Subject: RE: Parsing Schema Grammar - waiting for an answer
> >
> >Hi Ori,
> >
> >At 16.13 16/08/2006 +0200, Ori Doolman wrote:
> > >Alberto,
> > >Thank you for your answer.
> > >
> > >Still, I have some questions regarding your suggestion:
> > >
> > >1. How do you suggest to parse the grammar given in the xsd:schema
> > >element within the wsdl document?
> >
> >You don't have many options; you will have to serialize the DOM node
> >to a string and parse it with the special DOMBuilder (the one created
> >with your XMLGrammarPool object)
> >
> >
> > >2. Should I still use the loadGrammar API of DOMBuilder?
> >
> >Yes
> >
> >
> > >3. In your 1st solution, how do I get the grammar instance for
>calling
> > >grammar->getElemDecl(...
> >
> >You can still use DOMBuilder::getGrammar
> >
> >Alberto
> >
> >
> > >-----Original Message-----
> > >From: Alberto Massari [mailto:[EMAIL PROTECTED]
> > >Sent: Wednesday, August 16, 2006 10:16 AM
> > >To: [email protected]
> > >Subject: Re: Parsing Schema Grammar - waiting for an answer
> > >
> > >Hi Ori,
> > >
> > >At 09.40 16/08/2006 +0200, Ori Doolman wrote:
> > > >Hello,
> > > >
> > > >Since the grammar section is not documented and I couldn't find
my
> > > >answer elsewhere, I asked a question a few days ago (see my
>previous
> > > >email to this list), but still didn't get any answer.
> > > >
> > > >I'll appreciate your help.
> > >
> > >Your approach may work; you could avoid the enumeration of the
> > >elements in the grammar by:
> > >- creating an instance of XMLGrammarPoolImpl
> > >- instanciating the DOMBuilder using
> > >createDOMBuilder(MODE_SYNCHRONOUS, NULL,
> > >XMLPlatformUtils::fgMemoryManager, grammarPool)
> > >- using
> >
>
>grammar->getElemDecl(grammarPool->getURIStringPool()->getId("parlayx_ca
> >l
> > >l_notification_local_xsd"),
> > >"handleBusy", NULL, Grammar::TOP_LEVEL_SCOPE)
> > >
> > >Another option is building an XSModel using
>grammarPool->getXSModel().
> > >Then, use XSModel::getElementDeclaration("handleBusy",
> > >"parlayx_call_notification_local_xsd") and examine the element
> > >definition.
> > >This because the informations stored in the SchemaGrammar object
are
> > >optimized to validate the data, while the XSModel data structure
> > >tries to keep all the informations in the schema (including
> > >annotations).
> > >
> > >Hope this helps,
> > >Alberto


Reply via email to