From tdninh at tma.com.vn  Tue Oct 14 04:39:52 2008
From: tdninh at tma.com.vn (Ninh Tran Dang)
Date: Tue Oct 14 04:51:43 2008
Subject: [xsde-users] Generating skel for split schema
In-Reply-To: <20080618070313.GA18877@karelia>
References: <20080618070313.GA18877@karelia>
Message-ID: <029401c92dd8$6dde7090$7f8010ac@tdninh>

Hi Boris,

 

We have difficulty with skeleton code generation when breaking our schema to
smaller pieces of schemas. Currently our schema is too big, at the result of
this it generates very big skeleton codes. So we decided to split them to
smaller schemas and the main schema will include the split schemas.

 

And the problem here is the xsde binary doesn't know to generate skel codes
for the included schemas when we stay at the main schema.

 

Are there any other options of xsde where we could use to generate the whole
schema tree starting from the root schema?

 

Thanks,

Ninh

 

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Wednesday, June 18, 2008 2:03 PM
To: Ninh Tran Dang
Cc: xsde-users@codesynthesis.com
Subject: handling content of anyType

 

Hi Ninh,

 

In the future please send technical questions like these to the

xsde-users mailing list (which I've CC'ed) instead of to me directly.

This way other developers who may have experienced a similar problem

can provide you with a solution. Plus questions and answers will be

archived and available to others with similar problems.

 

 

Ninh Tran Dang <tdninh@tma.com.vn> writes:

 

> I have trouble when using XSDe to parse an empty element. The root parser

> class doesn't allow me to set the parser for the person element.

> 

> Because the element type under the root node is anyType, so it will accept

> all xml elements under the root provided they are validated themselves,
but

> in this case I cannot parse the xml document.

 

More precisely, anyType accepts any well-formed XML fragment. There

won't be any XML Schema validation though. For example, in the sample

XML you provided below, the person element won't be validated against

the person element defined in the schema.

 

 

> Could you answer me whether XSDe supports to parse this kind of schema? Or

> do we have anyway to overcome this situation?

 

Similar to wildcards (any and anyAttribute) all content matched by

anyType will be reported via the following "raw XML" callbacks:

 

  virtual void

  _start_any_element (const xml_schema::ro_string& ns,

                      const xml_schema::ro_string& name);

 

  virtual void

  _end_any_element (const xml_schema::ro_string& ns,

                    const xml_schema::ro_string& name);

 

  virtual void

  _any_attribute (const xml_schema::ro_string& ns,

                  const xml_schema::ro_string& name,

                  const xml_schema::ro_string& value);

 

  virtual void

  _any_characters (const xml_schema::ro_string&);

 

You can override them in root_pimpl. If you know that the content

matched by anyType can be parsed by some other parser (e.g., 

person_pimpl in the below example), then you can route these calls

to the corresponding parser. For more information on how to do

this refer to the wildcard example in examples/cxx/parser/wildcard/.

 

Boris

 

 

[The rest of the original email follows for context.]

 

> 

> Thanks,

> 

> Ninh

> 

> <root xsi:noNamespaceSchemaLocation="E:\temp\conf\question.xsd"

>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

> 

>  <person>

>    <first-name>String</first-name>

>    <last-name>String</last-name>

>  </person>

> 

> </root>

> 

>  

> 

> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

>            elementFormDefault="qualified" 

>            attributeFormDefault="unqualified">

> 

> <xs:element name="root">

>   <xs:complexType>

>     <xs:complexContent>

>       <xs:extension base="xs:anyType">

>       </xs:extension>

>     </xs:complexContent> 

>   </xs:complexType>

> </xs:element>

> 

> <xs:element name="person">

>   <xs:complexType>

>     <xs:sequence>

>       <xs:element name="first-name" type="xs:string"/>

>       <xs:element name="last-name" type="xs:string"/>

>     </xs:sequence>

>   </xs:complexType>

> </xs:element>

> 

> </xs:schema>

From boris at codesynthesis.com  Tue Oct 14 04:56:33 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Oct 14 04:58:31 2008
Subject: [xsde-users] Re: Generating skel for split schema
Message-ID: <20081014085633.GA8083@karelia>

Hi Ninh,

Ninh Tran Dang <tdninh@tma.com.vn> writes:

> And the problem here is the xsde binary doesn't know to generate skel 
> codes for the included schemas when we stay at the main schema.

You need to compile each schema separately. Let's say you have
schema1.xsd, schema2.xsd and master.xsd which includes the first
two schemas. You will need to run the XSD/e compiler on each
schema file:

$ xsde cxx-parser schema1.xsd
$ xsde cxx-parser schema2.xsd
$ xsde cxx-parser master.xsd

Or you can compile them all at once:

$ xsde cxx-parser schema1.xsd schema2.xsd master.xsd

Note also that for this to work each schema file should be valid
by itself (i.e., contain includes for all external types that it
references).

Boris

From tdninh at tma.com.vn  Tue Oct 14 05:25:31 2008
From: tdninh at tma.com.vn (Ninh Tran Dang)
Date: Tue Oct 14 05:39:24 2008
Subject: [xsde-users] RE: Generating skel for split schema
In-Reply-To: <20081014085633.GA8083@karelia>
References: <20081014085633.GA8083@karelia>
Message-ID: <02a401c92dde$cdefe350$7f8010ac@tdninh>

Hi Boris,

Thank you very much for your response, and currently we apply the first
choice because we have different map files.

Regards,
Ninh

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Tuesday, October 14, 2008 3:57 PM
To: Ninh Tran Dang
Cc: xsde-users@codesynthesis.com
Subject: Re: Generating skel for split schema

Hi Ninh,

Ninh Tran Dang <tdninh@tma.com.vn> writes:

> And the problem here is the xsde binary doesn't know to generate skel 
> codes for the included schemas when we stay at the main schema.

You need to compile each schema separately. Let's say you have
schema1.xsd, schema2.xsd and master.xsd which includes the first
two schemas. You will need to run the XSD/e compiler on each
schema file:

$ xsde cxx-parser schema1.xsd
$ xsde cxx-parser schema2.xsd
$ xsde cxx-parser master.xsd

Or you can compile them all at once:

$ xsde cxx-parser schema1.xsd schema2.xsd master.xsd

Note also that for this to work each schema file should be valid
by itself (i.e., contain includes for all external types that it
references).

Boris

From ntlkhuong at tma.com.vn  Tue Oct 28 05:44:56 2008
From: ntlkhuong at tma.com.vn (Khuong Nguyen Thi Lien)
Date: Tue Oct 28 05:48:26 2008
Subject: [xsde-users] Get the currently parsed element's name
In-Reply-To: <20080911085121.GB9675@karelia>
References: <20080910090831.GC6428@karelia>
	<007001c91328$3c60db90$828010ac@tma.com.vn>
	<20080911085121.GB9675@karelia>
Message-ID: <00a701c938e1$d683d1d0$43b010ac@tma.com.vn>

Hi Boris,

I have another situation that I want to retrieve the current element's name
where the parser is working on. Is there any data member where we could
extract this name?

Thanks,
Khuong

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Thursday, September 11, 2008 3:51 PM
To: Khuong Nguyen Thi Lien
Cc: xsde-users@codesynthesis.com
Subject: Re: [xsde-users] Get the element name

Hi Khuong,

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

> Sorry for the unclear question, I have the xml fragment below, when the
> parsing engine reaches the <greeting> element in the greeting() callback
> function, I would like to extract the name of the element right at this
> function. In this case I would like the returned name should be
"greeting". 

My guess is that your schema is using substitution groups and element
names act as identifiers (i.e., different substituting elements use the
same type). If that's the case then I have already outlined the possible
ways to achieve this in the following post:

http://www.codesynthesis.com/pipermail/xsde-users/2008-July/000039.html

In your case the easiest way would be to override _start_element and
save the element name in a member variable. You can then access it
from the greeting function:

struct hello_pimpl: hello_pskel
{
  virtual void
  greeting (const string& greeting)
  {
    // element_name_ contains the element name. 
  }

  virtual void
  name (const string& name)
  {
  }

  virtual void
  _start_element (const xml_schema::ro_string& ns,
                  const xml_schema::ro_string& name
                  const char* type)
  {
     element_name_ = name;

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

private:
  string element_name_;
};


Boris

From boris at codesynthesis.com  Tue Oct 28 06:36:51 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Oct 28 06:40:26 2008
Subject: [xsde-users] Get the currently parsed element's name
Message-ID: <20081028103651.GA10975@karelia>

Hi Khuong,

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

> I have another situation that I want to retrieve the current element's name
> where the parser is working on.

Is the technique outlined previously[1] not working for this situation?
If that's the case, then we will need more details about what you are
trying to achieve.

[1] http://www.codesynthesis.com/pipermail/xsde-users/2008-September/000051.html

Boris

From ntlkhuong at tma.com.vn  Tue Oct 28 23:36:32 2008
From: ntlkhuong at tma.com.vn (Khuong Nguyen Thi Lien)
Date: Tue Oct 28 23:40:02 2008
Subject: [xsde-users] Get the currently parsed element's name
In-Reply-To: <20081028103651.GA10975@karelia>
References: <20081028103651.GA10975@karelia>
Message-ID: <001d01c93977$89bfce30$43b010ac@tma.com.vn>


Hi Boris,

Thanks for you response, with the technique pointed out in [1], we can
retrieve the name of the child element which is supposed to be successively
parsed, my current situation is we want to retrieve the current element name
when the parser is processing on it. This could help us to create the object
with the name of the current element and return to the parent element.

Thanks,
Khuong

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Tuesday, October 28, 2008 5:37 PM
To: Khuong Nguyen Thi Lien
Cc: xsde-users@codesynthesis.com
Subject: Re: [xsde-users] Get the currently parsed element's name

Hi Khuong,

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

> I have another situation that I want to retrieve the current element's
name
> where the parser is working on.

Is the technique outlined previously[1] not working for this situation?
If that's the case, then we will need more details about what you are
trying to achieve.

[1]
http://www.codesynthesis.com/pipermail/xsde-users/2008-September/000051.html

Boris

From boris at codesynthesis.com  Wed Oct 29 02:32:49 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Oct 29 02:36:31 2008
Subject: [xsde-users] Get the currently parsed element's name
In-Reply-To: <001d01c93977$89bfce30$43b010ac@tma.com.vn>
References: <20081028103651.GA10975@karelia>
	<001d01c93977$89bfce30$43b010ac@tma.com.vn>
Message-ID: <20081029063249.GA14062@karelia>

Hi Khuong,

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

> Thanks for you response, with the technique pointed out in [1], we can
> retrieve the name of the child element which is supposed to be successively
> parsed, my current situation is we want to retrieve the current element name
> when the parser is processing on it. This could help us to create the object
> with the name of the current element and return to the parent element.

I understand now. There is no built-in support for this. In fact,
some types (i.e., simple types) can be used for both elements and
attributes. I see two ways to achieve what you want. Let's say we
have the following schema:

<complexType name="inner">
  <sequence>

    ...

  </sequence>
</complexType>

<complexType name="outer">
  <sequence>
    <element name="x" type="inner"/>
  </sequence>
</complexType>

Here we want to know the name of the element that is being parsed
('x' in our case) in the inner_pimpl parser implementation. With
the first approach you simply establish a connection between
inner_pimpl and outer_pimpl and use the same approach in
outer_pimpl as described previously:

struct inner_pimpl: inner_pskel
{
  inner_pimpl (const string& element_name)
    : element_name_ (element_name)
  {
  }

  virtual void
  pre ()
  {
    // element_name_ contains the element name we are parsing.
  }

private:
  const string& element_name_;
};

struct outer_pimpl: outer_pskel
{
  virtual void
  _start_element (const xml_schema::ro_string& ns,
                  const xml_schema::ro_string& name
                  const char* type)
  {
     element_name_ = name;

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

public:
  string element_name_;
};


Then, when you create your parsers, you establish the connection:

outer_pimpl outer_p;
inner_pimpl inner_p (outer_p.element_name_);

The second approach works best if you are passing the object from
inner_pimpl to outer_pimpl. Let's say we have the inner_t C++ type
corresponding to the inner XML Schema type:

struct inner_t
{
  ...

  string element_name_;
};

The idea is to set the element name in outer_pimpl:

struct inner_pimpl: inner_pskel
{
  virtual inner_t*
  post_inner ()
  {
    return new inner_t;
  }
};

struct outer_pimpl: outer_pskel
{
  virtual void
  x (inner_t* i)
  {
    i->element_name_ = element_name_; 
  }

  virtual void
  _start_element (const xml_schema::ro_string& ns,
                  const xml_schema::ro_string& name
                  const char* type)
  {
     element_name_ = name;

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

public:
  string element_name_;
};

Boris

From ntlkhuong at tma.com.vn  Wed Oct 29 03:57:01 2008
From: ntlkhuong at tma.com.vn (Khuong Nguyen Thi Lien)
Date: Wed Oct 29 04:00:36 2008
Subject: [xsde-users] Get the currently parsed element's name
In-Reply-To: <20081029063249.GA14062@karelia>
References: <20081028103651.GA10975@karelia>
	<001d01c93977$89bfce30$43b010ac@tma.com.vn>
	<20081029063249.GA14062@karelia>
Message-ID: <002e01c9399b$ed894440$43b010ac@tma.com.vn>

Hi Boris,

The second approach is what we current apply, but we are optimizing the code
size, so we try to minimize the consumed number of methods to create the
object right at the time it is being parsed and the second approach takes us
some steps to create the object including init and set value actions. The
first approach could help, but it needs us a lot of effort on creating the
connections between parser implementation classes which could reach to
thousands of classes in quantity. We are trying to figure out another
approach based on your explanation, otherwise we will apply the second
approach. Just let you know the status and thank you very much for your
prompt support.

Thanks,
Khuong

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Wednesday, October 29, 2008 1:33 PM
To: Khuong Nguyen Thi Lien
Cc: xsde-users@codesynthesis.com
Subject: Re: [xsde-users] Get the currently parsed element's name

Hi Khuong,

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

> Thanks for you response, with the technique pointed out in [1], we can
> retrieve the name of the child element which is supposed to be
successively
> parsed, my current situation is we want to retrieve the current element
name
> when the parser is processing on it. This could help us to create the
object
> with the name of the current element and return to the parent element.

I understand now. There is no built-in support for this. In fact,
some types (i.e., simple types) can be used for both elements and
attributes. I see two ways to achieve what you want. Let's say we
have the following schema:

<complexType name="inner">
  <sequence>

    ...

  </sequence>
</complexType>

<complexType name="outer">
  <sequence>
    <element name="x" type="inner"/>
  </sequence>
</complexType>

Here we want to know the name of the element that is being parsed
('x' in our case) in the inner_pimpl parser implementation. With
the first approach you simply establish a connection between
inner_pimpl and outer_pimpl and use the same approach in
outer_pimpl as described previously:

struct inner_pimpl: inner_pskel
{
  inner_pimpl (const string& element_name)
    : element_name_ (element_name)
  {
  }

  virtual void
  pre ()
  {
    // element_name_ contains the element name we are parsing.
  }

private:
  const string& element_name_;
};

struct outer_pimpl: outer_pskel
{
  virtual void
  _start_element (const xml_schema::ro_string& ns,
                  const xml_schema::ro_string& name
                  const char* type)
  {
     element_name_ = name;

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

public:
  string element_name_;
};


Then, when you create your parsers, you establish the connection:

outer_pimpl outer_p;
inner_pimpl inner_p (outer_p.element_name_);

The second approach works best if you are passing the object from
inner_pimpl to outer_pimpl. Let's say we have the inner_t C++ type
corresponding to the inner XML Schema type:

struct inner_t
{
  ...

  string element_name_;
};

The idea is to set the element name in outer_pimpl:

struct inner_pimpl: inner_pskel
{
  virtual inner_t*
  post_inner ()
  {
    return new inner_t;
  }
};

struct outer_pimpl: outer_pskel
{
  virtual void
  x (inner_t* i)
  {
    i->element_name_ = element_name_; 
  }

  virtual void
  _start_element (const xml_schema::ro_string& ns,
                  const xml_schema::ro_string& name
                  const char* type)
  {
     element_name_ = name;

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

public:
  string element_name_;
};

Boris

From boris at codesynthesis.com  Wed Oct 29 04:36:51 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Oct 29 04:40:36 2008
Subject: [xsde-users] Get the currently parsed element's name
In-Reply-To: <002e01c9399b$ed894440$43b010ac@tma.com.vn>
References: <20081028103651.GA10975@karelia>
	<001d01c93977$89bfce30$43b010ac@tma.com.vn>
	<20081029063249.GA14062@karelia>
	<002e01c9399b$ed894440$43b010ac@tma.com.vn>
Message-ID: <20081029083651.GA14663@karelia>

Hi Khuong,

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

> The second approach is what we current apply, but we are optimizing the code
> size, so we try to minimize the consumed number of methods to create the
> object right at the time it is being parsed and the second approach takes us
> some steps to create the object including init and set value actions. The
> first approach could help, but it needs us a lot of effort on creating the
> connections between parser implementation classes which could reach to
> thousands of classes in quantity. We are trying to figure out another
> approach based on your explanation, otherwise we will apply the second
> approach.

My understanding was that you have just a few places where you need
element names. If you need it in every parser and the number of
parsers is large then the suggested two approaches can require
quite a bit of work. In this case another approach can be a better
fit. Its main disadvantage is that it requires a few modifications
to the XSD/e runtime.

There is a notion of parsing context that is available to all parsers
via the _context() function. The context class is defined in the 
libxsde/xsde/cxx/parser/context.* files. We can modify this context
class to also include the current element name. For example we can
add it after the xml_parser_ variable at line 131 (using the XSD/e 
2.1.0 source code):

protected:
  XML_Parser xml_parser_;

public:
  const char* element_name_;
};

The other change that we need to make is to set this name. For that
we need to add the following line in 
libxsde/xsde/cxx/parser/expat/document.cxx, after line 593:

context_.element_name_ = name_p;

Now we can implement inner_pimpl like so:

struct inner_pimpl: inner_pskel
{
  virtual void
  pre ()
  {
    const char* name = _context ().element_name_;
  }
};

Note also that with this approach _context ().element_name_ always
contains the latest element seen. So for example if inner contained
a nested element then in inner_post() _context ().element_name_ would
contain this nested element's name, not the one that we need. In other
words, you need to save the element name in pre() unless the type has
no nested elements.

Let me know if you run into any problems with this.

Boris

From tdninh at tma.com.vn  Fri Oct 31 01:01:55 2008
From: tdninh at tma.com.vn (Ninh Tran Dang)
Date: Fri Oct 31 02:33:53 2008
Subject: [xsde-users] Get the currently parsed element's name
In-Reply-To: <20081029083651.GA14663@karelia>
References: <20081028103651.GA10975@karelia>
	<001d01c93977$89bfce30$43b010ac@tma.com.vn>
	<20081029063249.GA14062@karelia>
	<002e01c9399b$ed894440$43b010ac@tma.com.vn>
	<20081029083651.GA14663@karelia>
Message-ID: <003c01c93b15$cc4ed440$738010ac@tdninh>

Hi Boris,

We tried with your new suggestion, it's ok when retrieving the element's
name from the pre() with the "const char* name = _context ().element_name_"
statement. But it got the segmentation fault when getting this from the
post() method. Even we tried in the post() of element that doesn't contain
the nested elements.

Do you know the reason why we got this error?

Thanks,
Ninh

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Wednesday, October 29, 2008 3:37 PM
To: Khuong Nguyen Thi Lien
Cc: xsde-users@codesynthesis.com; 'Ninh Tran Dang'; 'Duy Chau Hai'; 'Thien
Le Minh'; gqminh@tma.com.vn
Subject: Re: [xsde-users] Get the currently parsed element's name

Hi Khuong,

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

> The second approach is what we current apply, but we are optimizing the
code
> size, so we try to minimize the consumed number of methods to create the
> object right at the time it is being parsed and the second approach takes
us
> some steps to create the object including init and set value actions. The
> first approach could help, but it needs us a lot of effort on creating the
> connections between parser implementation classes which could reach to
> thousands of classes in quantity. We are trying to figure out another
> approach based on your explanation, otherwise we will apply the second
> approach.

My understanding was that you have just a few places where you need
element names. If you need it in every parser and the number of
parsers is large then the suggested two approaches can require
quite a bit of work. In this case another approach can be a better
fit. Its main disadvantage is that it requires a few modifications
to the XSD/e runtime.

There is a notion of parsing context that is available to all parsers
via the _context() function. The context class is defined in the 
libxsde/xsde/cxx/parser/context.* files. We can modify this context
class to also include the current element name. For example we can
add it after the xml_parser_ variable at line 131 (using the XSD/e 
2.1.0 source code):

protected:
  XML_Parser xml_parser_;

public:
  const char* element_name_;
};

The other change that we need to make is to set this name. For that
we need to add the following line in 
libxsde/xsde/cxx/parser/expat/document.cxx, after line 593:

context_.element_name_ = name_p;

Now we can implement inner_pimpl like so:

struct inner_pimpl: inner_pskel
{
  virtual void
  pre ()
  {
    const char* name = _context ().element_name_;
  }
};

Note also that with this approach _context ().element_name_ always
contains the latest element seen. So for example if inner contained
a nested element then in inner_post() _context ().element_name_ would
contain this nested element's name, not the one that we need. In other
words, you need to save the element name in pre() unless the type has
no nested elements.

Let me know if you run into any problems with this.

Boris

From boris at codesynthesis.com  Fri Oct 31 03:06:58 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Oct 31 03:10:58 2008
Subject: [xsde-users] Get the currently parsed element's name
In-Reply-To: <003c01c93b15$cc4ed440$738010ac@tdninh>
References: <20081028103651.GA10975@karelia>
	<001d01c93977$89bfce30$43b010ac@tma.com.vn>
	<20081029063249.GA14062@karelia>
	<002e01c9399b$ed894440$43b010ac@tma.com.vn>
	<20081029083651.GA14663@karelia>
	<003c01c93b15$cc4ed440$738010ac@tdninh>
Message-ID: <20081031070658.GA22027@karelia>

Hi Ninh,

Ninh Tran Dang <tdninh@tma.com.vn> writes:

> We tried with your new suggestion, it's ok when retrieving the element's
> name from the pre() with the "const char* name = _context ().element_name_"
> statement. But it got the segmentation fault when getting this from the
> post() method. Even we tried in the post() of element that doesn't contain
> the nested elements.
> 
> Do you know the reason why we got this error?

I think I do: post() is called after the end_element SAX even arrives
while the element name was saved in start_element. Expat (the underlying
parser) probably frees or reuses the name buffer after start_element
which makes it unusable. Sorry, I was too optimistic about types
without nested elements. 

After thinking some more about this, I believe this can be fixed by
adding a similar line of code to end_element_() in 
libxsde/xsde/cxx/parser/expat/document.cxx, after line 879, as we've 
added to start_element_():

context_.element_name_ = name_p;

This way the element name in the context will be restored for the
post() call. The really nice thing about it is that you can now
use _context ().element_name_ from post() even for types that have 
nested elements!

Boris

From tdninh at tma.com.vn  Fri Oct 31 04:15:56 2008
From: tdninh at tma.com.vn (Ninh Tran Dang)
Date: Fri Oct 31 04:20:12 2008
Subject: [xsde-users] Get the currently parsed element's name
In-Reply-To: <20081031070658.GA22027@karelia>
References: <20081028103651.GA10975@karelia>
	<001d01c93977$89bfce30$43b010ac@tma.com.vn>
	<20081029063249.GA14062@karelia>
	<002e01c9399b$ed894440$43b010ac@tma.com.vn>
	<20081029083651.GA14663@karelia>
	<003c01c93b15$cc4ed440$738010ac@tdninh>
	<20081031070658.GA22027@karelia>
Message-ID: <004501c93b30$e6f7fa90$738010ac@tdninh>

Hi Boris,

We still got segmentation fault with your instruction. In the worst case, we
will use the "const char* name = _context ().element_name_" in the pre()
method and then create the object with the stored name variable in the
post(), we tried and found that it works. But we are not sure if there is
any further risk because the name variable also points to the element_name
member of context class which is somehow freed previously.

Thanks,
Ninh

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Friday, October 31, 2008 2:07 PM
To: Ninh Tran Dang
Cc: xsde-users@codesynthesis.com
Subject: Re: [xsde-users] Get the currently parsed element's name

Hi Ninh,

Ninh Tran Dang <tdninh@tma.com.vn> writes:

> We tried with your new suggestion, it's ok when retrieving the element's
> name from the pre() with the "const char* name = _context
().element_name_"
> statement. But it got the segmentation fault when getting this from the
> post() method. Even we tried in the post() of element that doesn't contain
> the nested elements.
> 
> Do you know the reason why we got this error?

I think I do: post() is called after the end_element SAX even arrives
while the element name was saved in start_element. Expat (the underlying
parser) probably frees or reuses the name buffer after start_element
which makes it unusable. Sorry, I was too optimistic about types
without nested elements. 

After thinking some more about this, I believe this can be fixed by
adding a similar line of code to end_element_() in 
libxsde/xsde/cxx/parser/expat/document.cxx, after line 879, as we've 
added to start_element_():

context_.element_name_ = name_p;

This way the element name in the context will be restored for the
post() call. The really nice thing about it is that you can now
use _context ().element_name_ from post() even for types that have 
nested elements!

Boris

From boris at codesynthesis.com  Fri Oct 31 04:58:20 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Oct 31 05:02:20 2008
Subject: [xsde-users] Get the currently parsed element's name
In-Reply-To: <004501c93b30$e6f7fa90$738010ac@tdninh>
References: <20081028103651.GA10975@karelia>
	<001d01c93977$89bfce30$43b010ac@tma.com.vn>
	<20081029063249.GA14062@karelia>
	<002e01c9399b$ed894440$43b010ac@tma.com.vn>
	<20081029083651.GA14663@karelia>
	<003c01c93b15$cc4ed440$738010ac@tdninh>
	<20081031070658.GA22027@karelia>
	<004501c93b30$e6f7fa90$738010ac@tdninh>
Message-ID: <20081031085820.GC22027@karelia>

Hi Ninh,

Ninh Tran Dang <tdninh@tma.com.vn> writes:

> We still got segmentation fault with your instruction. In the worst case, we
> will use the "const char* name = _context ().element_name_" in the pre()
> method and then create the object with the stored name variable in the
> post(), we tried and found that it works. But we are not sure if there is
> any further risk because the name variable also points to the element_name
> member of context class which is somehow freed previously.

Ok, I've decided to test the changes I have outlined in my previous
emails on the library example. While setting element_name_ in context
works as expected, there is one thing I stated incorrectly: the parsing
context is not available in the pre() and post_xxx() callbacks. It is
only available between (and including) _pre() and _post(). As you may
remember from the documentation, each parser has four special callbacks:
pre(), _pre(), _post(), and post_xxx(). The callback are called in this
order:

pre()
_pre()
<attribute callbacks>
<nested element callbacks>
_post()
post_xxx()

The call to _context() is only valid starting from _pre() and
ending with _post(). If you are creating the object in post_xxx(),
one way to change your code would be as follows:

struct inner_pimpl: inner_pskel
{
  virtual void
  _post ()
  {
    const char* name = _context ().element_name_;
    ret_ = new inner_t (name);
  }

  virtual inner_t*
  post_inner ()
  {  
    return ret_;
  }  

private:
  inner_t* ret_;
};

Alternatively, you can save a copy of the name in _pre() or _post() 
and then use that copy in post_xxx():

struct inner_pimpl: inner_pskel
{
  virtual void
  _post ()
  {
    element_name_ = strdup (_context ().element_name_);
  }

  virtual inner_t*
  post_inner ()
  {  
    return new inner_t (element_name_); // Assumes ownership of element_name_.
  }  

private:
  char* element_name_;
};

If you are already using pre() and would like to keep the number of
callbacks to a minimum then you can just replace pre() with _pre()
and save the element name there. The only requirement is that in
_pre() you always need to call the version from the base parser
if there is one. For more information on the difference between
pre() and _pre(), see Section 3.1 in Chapter 3, "Parser Skeletons"
in the Embedded C++/Parser Mapping Getting Started Guide:

http://www.codesynthesis.com/projects/xsde/documentation/cxx/parser/guide/#3.1

Boris