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

[Jonathan Haws]

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