From KOppenheim at nextpointnetworks.com  Thu Jul  3 18:09:33 2008
From: KOppenheim at nextpointnetworks.com (Keith Oppenheim)
Date: Fri Jul  4 02:47:39 2008
Subject: [xsde-users] Cannot get the value
In-Reply-To: <20080625132520.GK12421@karelia>
References: <002f01c8d6a8$f0467be0$43b010ac@tma.com.vn>
	<20080625132520.GK12421@karelia>
Message-ID: <1C6541574A2FC447B53A6B4522B678AF025847A0@moe.nextone.local>

Hi Boris,

The schema fragment attached by Khuong comes directly from the NETCONF
schema defined in RFC 4741.  The schema defines a <source> element
that's nested inside of a <get-config> element.  The <source> element is
of type="getConfigSourceType":

<xs:complexType name="getConfigSourceType">
     <xs:choice>
         <xs:element ref="config-name"/>
         <xs:element name="url" type="configURIType"/>
     </xs:choice>
</xs:complexType>

The schema is structured to give the user flexibility in defining the
element nested within <source>.  The user can nest one of <running/>,
<candidate/>, or <startup/> elements within <source>.  Alternatively,
via the substitution group mechanism, the user can nest any user-defined
element as long as it derives from configNameType and uses <config-name>
as the head of its substitution group. 

Regards,

Keith Oppenheim
NextPoint Networks, Inc.
 
-----Original Message-----
From: xsde-users-bounces@codesynthesis.com
[mailto:xsde-users-bounces@codesynthesis.com] On Behalf Of Boris
Kolpackov
Sent: Wednesday, June 25, 2008 9:25 AM
To: Khuong Nguyen Thi Lien
Cc: xsde-users@codesynthesis.com
Subject: Re: [xsde-users] Cannot get the value

Hi Khuong,

Khuong Nguyen Thi Lien <ntlkhuong@tma.com.vn> writes:

> <xs:complexType name="configNameType"/>
> 
>             <xs:element name="config-name" type="configNameType"
> abstract="true"/>
> 
>             <xs:element name="startup" type="configNameType"
> substitutionGroup="config-name"/>
> 
>             <xs:element name="candidate" type="configNameType"
> substitutionGroup="config-name"/>
> 
>             <xs:element name="running" type="configNameType"
> substitutionGroup="config-name"/>
> 

This schema does not make much sense since the elements that substitute
config-name (startup, candidate, and running) all use the same type as
config-name. Normally you would have types derived from configNameType
for startup, candidate, and running, for example (normally such types
would also include additional elements/attributes):

<xs:complexType name="startupType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="startup" type="startupType" 
            substitutionGroup="config-name"/>

<xs:complexType name="candidateType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="candidate" type="candidateType" 
            substitutionGroup="config-name"/>

<xs:complexType name="runningType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="running" type="runningType" 
            substitutionGroup="config-name"/>


Then you would implement parser skeletons for each of them and
add them to the map that is used to parse config-name. During
parsing, depending on the actual element name found in XML (e.g.,
running, startup, etc.), the corresponding parser skeleton will
be executed.

Boris


From boris at codesynthesis.com  Fri Jul  4 10:13:54 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Jul  4 10:16:59 2008
Subject: [xsde-users] Cannot get the value
In-Reply-To: <1C6541574A2FC447B53A6B4522B678AF025847A0@moe.nextone.local>
References: <002f01c8d6a8$f0467be0$43b010ac@tma.com.vn>
	<20080625132520.GK12421@karelia>
	<1C6541574A2FC447B53A6B4522B678AF025847A0@moe.nextone.local>
Message-ID: <20080704141354.GD27211@karelia>

Hi Keith,

Keith Oppenheim <KOppenheim@nextpointnetworks.com> writes:

> The schema fragment attached by Khuong comes directly from the NETCONF
> schema defined in RFC 4741.  The schema defines a <source> element
> that's nested inside of a <get-config> element.  The <source> element is
> of type="getConfigSourceType":
> 
> <xs:complexType name="getConfigSourceType">
>      <xs:choice>
>          <xs:element ref="config-name"/>
>          <xs:element name="url" type="configURIType"/>
>      </xs:choice>
> </xs:complexType>
> 
> The schema is structured to give the user flexibility in defining the
> element nested within <source>.  The user can nest one of <running/>,
> <candidate/>, or <startup/> elements within <source>.  Alternatively,
> via the substitution group mechanism, the user can nest any user-defined
> element as long as it derives from configNameType and uses <config-name>
> as the head of its substitution group. 

Did I understand this correctly: the running, candidate, and startup
elements do not carry any information other than just their names since
they are of the same empty configNameType type? In other words they
act as tags or type ids of some sort?

If that's the case then the trouble with using XSD/e in this kind of
situation is that the generated code handles XML Schema polymorphism
(xsi:type and substitution groups) transparently. It figures out the
type of parser that should be used and calls it. This is normally
exactly what you want since in most cases the substituting elements
have different types. But in this case the name of the element is
the only information.

I can see two ways to handle this. First is to modify the schema
to assign different (but still empty) types to running, candidate,
and startup:

<xs:complexType name="startupType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="startup" type="startupType" 
            substitutionGroup="config-name"/>

<xs:complexType name="candidateType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="candidate" type="candidateType" 
            substitutionGroup="config-name"/>

<xs:complexType name="runningType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="running" type="runningType" 
            substitutionGroup="config-name"/>

The resulting schema will be semantically equivalent to the original
but now you can determine which element was specified based on the
parser that has been called.

The second approach does not require schema modification and involves
overriding low-level _start_element() function to detect the element
name:

class getConfigSourceType_pimpl: getConfigSourceType_pskel
{
public:
  virtual void
  _start_element (const xml_schema::ro_string& ns,
                  const xml_schema::ro_string& name
                  const char* type)
  {
     if (ns == "...")
     {
       if (name == "running")
       {
         // running element
       }
       else if (name == "candidate")
       {
         // candidate element
       }
       else if (name == "startup")
       { 
         // startup element
       }
     }

     // Always call the base _start_element().
     //
     getConfigSourceType_pskel::_start_element (ns, name, type);
  }

  ...
};

Boris

From ntlkhuong at tma.com.vn  Wed Jul 16 06:59:39 2008
From: ntlkhuong at tma.com.vn (Khuong Nguyen Thi Lien)
Date: Wed Jul 16 07:00:35 2008
Subject: [xsde-users] Serializer/Parser with anyType
In-Reply-To: <20080704141354.GD27211@karelia>
References: <002f01c8d6a8$f0467be0$43b010ac@tma.com.vn>
	<20080625132520.GK12421@karelia>
	<1C6541574A2FC447B53A6B4522B678AF025847A0@moe.nextone.local>
	<20080704141354.GD27211@karelia>
Message-ID: <002f01c8e733$0b908c70$43b010ac@tma.com.vn>


Hi Boris , 
Thank you so much for your support last time. I have applied your suggestion
successfully.

Currently , with the new XSD/e release (2.1.0) , I have some following
questions:

1. How to serialize the element "ok" as the below schema fragment:

<xs:complexType name="rpcReplyType">
		<xs:choice>
			<xs:element name="ok"/>
			<xs:group ref="rpcResponse"/>
		</xs:choice>
		<xs:attribute name="message-id" type="messageIdType"
use="optional"/>
		<xs:anyAttribute processContents="lax"/>
		<!--
         Any attributes supplied with <rpc> element must be returned
         on <rpc-reply>.
       -->
	</xs:complexType>



2. How to parse the element "select" as the below schema fragment:

	<xs:complexType name="filterInlineType">
		<xs:complexContent>
			<xs:extension base="xs:anyType">
				<xs:attribute name="type" type="FilterType"
default="subtree"/>
				<xs:attribute name="select"/>
			</xs:extension>
			<!-- if type="xpath", the xpath expression
           appears in the select element -->
		</xs:complexContent>
	</xs:complexType>
	


Thanks and best regards,
Khuong

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Friday, July 04, 2008 9:14 PM
To: Keith Oppenheim
Cc: Khuong Nguyen Thi Lien; xsde-users@codesynthesis.com
Subject: Re: [xsde-users] Cannot get the value

Hi Keith,

Keith Oppenheim <KOppenheim@nextpointnetworks.com> writes:

> The schema fragment attached by Khuong comes directly from the NETCONF
> schema defined in RFC 4741.  The schema defines a <source> element
> that's nested inside of a <get-config> element.  The <source> element is
> of type="getConfigSourceType":
> 
> <xs:complexType name="getConfigSourceType">
>      <xs:choice>
>          <xs:element ref="config-name"/>
>          <xs:element name="url" type="configURIType"/>
>      </xs:choice>
> </xs:complexType>
> 
> The schema is structured to give the user flexibility in defining the
> element nested within <source>.  The user can nest one of <running/>,
> <candidate/>, or <startup/> elements within <source>.  Alternatively,
> via the substitution group mechanism, the user can nest any user-defined
> element as long as it derives from configNameType and uses <config-name>
> as the head of its substitution group. 

Did I understand this correctly: the running, candidate, and startup
elements do not carry any information other than just their names since
they are of the same empty configNameType type? In other words they
act as tags or type ids of some sort?

If that's the case then the trouble with using XSD/e in this kind of
situation is that the generated code handles XML Schema polymorphism
(xsi:type and substitution groups) transparently. It figures out the
type of parser that should be used and calls it. This is normally
exactly what you want since in most cases the substituting elements
have different types. But in this case the name of the element is
the only information.

I can see two ways to handle this. First is to modify the schema
to assign different (but still empty) types to running, candidate,
and startup:

<xs:complexType name="startupType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="startup" type="startupType" 
            substitutionGroup="config-name"/>

<xs:complexType name="candidateType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="candidate" type="candidateType" 
            substitutionGroup="config-name"/>

<xs:complexType name="runningType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="running" type="runningType" 
            substitutionGroup="config-name"/>

The resulting schema will be semantically equivalent to the original
but now you can determine which element was specified based on the
parser that has been called.

The second approach does not require schema modification and involves
overriding low-level _start_element() function to detect the element
name:

class getConfigSourceType_pimpl: getConfigSourceType_pskel
{
public:
  virtual void
  _start_element (const xml_schema::ro_string& ns,
                  const xml_schema::ro_string& name
                  const char* type)
  {
     if (ns == "...")
     {
       if (name == "running")
       {
         // running element
       }
       else if (name == "candidate")
       {
         // candidate element
       }
       else if (name == "startup")
       { 
         // startup element
       }
     }

     // Always call the base _start_element().
     //
     getConfigSourceType_pskel::_start_element (ns, name, type);
  }

  ...
};

Boris
From boris at codesynthesis.com  Wed Jul 16 07:37:42 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jul 16 07:42:25 2008
Subject: [xsde-users] Serializer/Parser with anyType
In-Reply-To: <002f01c8e733$0b908c70$43b010ac@tma.com.vn>
References: <002f01c8d6a8$f0467be0$43b010ac@tma.com.vn>
	<20080625132520.GK12421@karelia>
	<1C6541574A2FC447B53A6B4522B678AF025847A0@moe.nextone.local>
	<20080704141354.GD27211@karelia>
	<002f01c8e733$0b908c70$43b010ac@tma.com.vn>
Message-ID: <20080716113742.GC12679@karelia>

Hi Khuong,

Khuong Nguyen Thi Lien <ntlkhuong@tma.com.vn> writes:

> 1. How to serialize the element "ok" as the below schema fragment:
> 
>       <xs:complexType name="rpcReplyType">
> 		<xs:choice>
> 			<xs:element name="ok"/>
> 			<xs:group ref="rpcResponse"/>
> 		</xs:choice>
> 		<xs:attribute name="message-id" type="messageIdType" use="optional"/>
> 		<xs:anyAttribute processContents="lax"/>
> 	</xs:complexType>

Element 'ok' is (implicitly) of type xsd:anyType which is a special
type that can contain any attributes/elements/text in any order.
To serialize an element of this type you will need to implement
the xml_schema::any_type_sskel serializer skeleton, for example:


struct ok_any_type_simpl: xml_schema::any_type_sskel
{
  virtual void
  _serialize_attributes ()
  {
     ...
  }

  virtual void
  _serialize_content ()
  {
     ...
  }
};

Inside the _serialize_attributes() and _serialize_content()
functions you would normally call the low-level XML serialization
function as described in Section 5.4, "Element Wildcard Callbacks"
in the Embedded C++/Serializer Mapping Getting Started Guide:

http://www.codesynthesis.com/projects/xsde/documentation/cxx/serializer/guide/#5.4

In case all you need is an empty 'ok' element, then you can simply use
the default xml_schema::any_type_simpl provided by the XSD/e runtime.


> 2. How to parse the element "select" as the below schema fragment:
> 
> 	<xs:complexType name="filterInlineType">
> 		<xs:complexContent>
> 			<xs:extension base="xs:anyType">
> 				<xs:attribute name="type" type="FilterType" default="subtree"/>
> 				<xs:attribute name="select"/>
> 			</xs:extension>
> 			<!-- if type="xpath", the xpath expression
>            appears in the select element -->
> 		</xs:complexContent>
> 	</xs:complexType>

Similarly to the previous case, attribute 'select' is (implicitly) of
type xsd:anySimpleType which is a special type that can contain any
text. To parse an element of this type you will need to implement
the xml_schema::any_simple_type_pskel parser skeleton, for example:

struct select_any_simple_type_pimpl: xml_schema::any_simple_type_pskel
{
  virtual void
  _any_characters (const xml_schema::ro_string& s)
  {
    // s contains raw character data
  }
};

Boris

From KOppenheim at nextpointnetworks.com  Wed Jul 16 17:32:51 2008
From: KOppenheim at nextpointnetworks.com (Keith Oppenheim)
Date: Thu Jul 17 02:02:22 2008
Subject: [xsde-users] Cannot get the value
In-Reply-To: <20080704141354.GD27211@karelia>
References: <002f01c8d6a8$f0467be0$43b010ac@tma.com.vn>
	<20080625132520.GK12421@karelia>
	<1C6541574A2FC447B53A6B4522B678AF025847A0@moe.nextone.local>
	<20080704141354.GD27211@karelia>
Message-ID: <1C6541574A2FC447B53A6B4522B678AF02690E3A@moe.nextone.local>

Hi Boris,

Thanks for your response.  Yes, you're correct - the running, candidate,
and startup
elements do not carry any information other than just their names since
they are of the same empty configNameType type.  They simply
act as identifiers.

Regards,

Keith Oppenheim 
-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Friday, July 04, 2008 10:14 AM
To: Keith Oppenheim
Cc: Khuong Nguyen Thi Lien; xsde-users@codesynthesis.com
Subject: Re: [xsde-users] Cannot get the value

Hi Keith,

Keith Oppenheim <KOppenheim@nextpointnetworks.com> writes:

> The schema fragment attached by Khuong comes directly from the NETCONF
> schema defined in RFC 4741.  The schema defines a <source> element
> that's nested inside of a <get-config> element.  The <source> element
is
> of type="getConfigSourceType":
> 
> <xs:complexType name="getConfigSourceType">
>      <xs:choice>
>          <xs:element ref="config-name"/>
>          <xs:element name="url" type="configURIType"/>
>      </xs:choice>
> </xs:complexType>
> 
> The schema is structured to give the user flexibility in defining the
> element nested within <source>.  The user can nest one of <running/>,
> <candidate/>, or <startup/> elements within <source>.  Alternatively,
> via the substitution group mechanism, the user can nest any
user-defined
> element as long as it derives from configNameType and uses
<config-name>
> as the head of its substitution group. 

Did I understand this correctly: the running, candidate, and startup
elements do not carry any information other than just their names since
they are of the same empty configNameType type? In other words they
act as tags or type ids of some sort?

If that's the case then the trouble with using XSD/e in this kind of
situation is that the generated code handles XML Schema polymorphism
(xsi:type and substitution groups) transparently. It figures out the
type of parser that should be used and calls it. This is normally
exactly what you want since in most cases the substituting elements
have different types. But in this case the name of the element is
the only information.

I can see two ways to handle this. First is to modify the schema
to assign different (but still empty) types to running, candidate,
and startup:

<xs:complexType name="startupType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="startup" type="startupType" 
            substitutionGroup="config-name"/>

<xs:complexType name="candidateType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="candidate" type="candidateType" 
            substitutionGroup="config-name"/>

<xs:complexType name="runningType">
  <complexContent>
    <extension base="configNameType"/>
  </complexContent>
</xs:complexType>

<xs:element name="running" type="runningType" 
            substitutionGroup="config-name"/>

The resulting schema will be semantically equivalent to the original
but now you can determine which element was specified based on the
parser that has been called.

The second approach does not require schema modification and involves
overriding low-level _start_element() function to detect the element
name:

class getConfigSourceType_pimpl: getConfigSourceType_pskel
{
public:
  virtual void
  _start_element (const xml_schema::ro_string& ns,
                  const xml_schema::ro_string& name
                  const char* type)
  {
     if (ns == "...")
     {
       if (name == "running")
       {
         // running element
       }
       else if (name == "candidate")
       {
         // candidate element
       }
       else if (name == "startup")
       { 
         // startup element
       }
     }

     // Always call the base _start_element().
     //
     getConfigSourceType_pskel::_start_element (ns, name, type);
  }

  ...
};

Boris