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

Boris Kolpackov boris at codesynthesis.com
Fri Dec 23 07:35:50 EST 2011


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



More information about the xsde-users mailing list