[xsde-users] xs:any and xs:anyAttribute

[Jonathan Haws]

Boris,

Okay, here is where I am at:

I am successfully parsing any XML file that is passed in.  Right now, I am ignoring all the xs:any fields and just pulling the information out of the top-level elements (event and point).  I am also able to generate code for all the sub-schemas and have found where I can tie into the parser to start parsing the sub-schemas.  I can also generate a basic XML document that is validated to the schema.

Things are looking good.

My next question is how can I deal with name conflicts between two sub-schemas?  For example, I have two sub-schemas; one called image and one called sensor.  Both define a field of view (fov) attribute.  When I try to link both of those sub-schemas into my test application, I get "multiple definition" errors.  Can this be avoided (i.e. can I provide a way to ensure that the symbol names are unique)?  Ideally I would have something like sensor_fov_pimpl::pre() and image_fov_pimpl::pre() instead of just fov_pimpl::pre() for both schemas.  Can this be done?

I am feeling like if I can get the object files to link in, I can then start into adding my own code for the _start_any_element call.

Thanks!

Jonathan


-----Original Message-----
From: xsde-users-bounces at codesynthesis.com [mailto:xsde-users-bounces at codesynthesis.com] On Behalf Of Jonathan Haws
Sent: Friday, December 23, 2011 15:46
To: Boris Kolpackov
Cc: xsde-users at codesynthesis.com
Subject: RE: [xsde-users] xs:any and xs:anyAttribute

Boris,

Thanks for all the help.  I think the pieces are falling together in my head now.  I am seeing a few with the generated code (some schemas don't produce code that will compile).  I will post those when I get a chance to see if it is something on my end.

However, now that I have a better understanding of how things work, writing the start_any_element routines should not be a big deal.  I think my biggest hangup was seeing how things all fit together.

Thanks for the help!  I will get back into this after the holidays.

Have a Merry Christmas and a happy New Year!

Jonathan


-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com] 
Sent: Friday, December 23, 2011 05:36
To: Jonathan Haws
Cc: xsde-users at codesynthesis.com
Subject: Re: [xsde-users] xs:any and xs:anyAttribute

Hi Jonathan,

Jonathan Haws <Jonathan.Haws at sdl.usu.edu> writes:

> In the wildcard examples, how does the driver know that the xs:any is 
> an envelope? It seems that it is fine with how it is setup now, with 
> envelope being the only option.  But let's say that we have two 
> different envelopes - a square and a rectangle.  How does the driver 
> distinguish that when making the call to _post()?

In the wildcard example, the xsd:any content is either the 'text' or 'binary' element, not 'envelope'. In the example the driver uses the element name to figure out which parser to use. Look at the implementations of the _start_any_element() and _end_any_element() functions -- all this is happening there. The code is also extensively commented.


> In my situation, I have a number of possibilities.  And the stuff in 
> <detail> can be any number of things - a <color>, a <shape>, or 
> something else.  Is there an example of that?  Or am I missing 
> something?

Yes, the 'text' and 'binary' elements are the examples of that.


> I guess my biggest question lies in how to get the sub-schema parsers 
> tied into the main parser.  The wildcard example is not clear to me on 
> how that is done.

Again, study the implementations of the _start_any_element() and
_end_any_element() functions.


> <event>
>   <point/>
>   <detail>
>     <!-- Varied schema(s) found in separate file is added here -->
>   </detail>
> </event>
>
> [...] 
>
> Is this a correct statement:  when the top-level parser gets to 
> the <detail> element, it recognizes that what is in <detail> 
> are xs:any fields. At this point it hands parsing off to the
> _start_any_element routine.

Yes, that's correct.


> When a valid XML tag is found, it pulls the name of that tag and
> calls the appropriate parser for that tag, then moves onto the
> next one. Is that correct?

This how it works for the normal, "statically typed" content. For
the wildcard (untyped) content, the parser simply routs all the XML
content to the _*_any_*() functions. You can then figure out what
kind of content it is (e.g., 'color', 'shape') by, for example,
comparing element names, and then forward this content to the
appropriate parser. This exactly what the 'wildcard' example does.


> Will XSD/e generate the function table for that if I provide it 
> the correct options?

No. With the wildcard content XSD/e has no knowledge of what can
possibly be there. So it is your job to figure out what it is
and decide what to do with it. Some applications, for example,
may not want to parse the (unknown) wildcard content but rather
store it in some raw XML format (e.g., DOM) in order to be able
to re-create the document.


> Again, what I am looking for is a way to setup a makefile that 
> will generate and tie together all the parsing and serialization 
> code.  Then all I need to do is write the driver.

I think for that you will need to contact some AI guys ;-).

Boris