[xsd-users] import, include, namespaces, restriction and schema versioning

[Boris Kolpackov]

Hi Eric,

Eric Niebler <eric at boostpro.com> writes:

> > (2) Notify the user somehow about missing elements, presumably,     
> > during parsing.
>
> I wasn't thinking of that. By "user" you mean me, the user of CodeSynth,  
> right?

Right.


> And by "notify" you mean invoke a registered callback. 

Correct.


> Huh, could be useful, but is beyond my basic needs.

Without this mechanism you (or someone else) will have to maintain
code which "knows" about all the additions to the vocabulary and
check the document for their absence. I think it would be a good
idea to automate this task. For example, with the callback approach
I described in my previous email, if you forget to actually implement
it, you will get a compiler/linker error.

I agree, though, that if most of your additions are covered by the
default values feature, this mechanism is not critical.


> > Wouldn't this be more naturally done during parsing so that the
> > application developer doesn't have to worry about missing elements?
>
> More naturally? Why? My intention is that the resulting XML produced by  
> our tools is always in the most up-to-date form and doesn't need to be  
> read back in in order to be patched up.

The output XML will be the same regardless of when you do the fixup, on
read or on write. However, if you do it on read, the application itself
will only need to know about the latest version of the schema. If the
fixup is done on write, the application should be prepared to handle
both old and new document versions.


> But the fix-up-on-write thought is beyond my basic needs. For my  
> scenario, what I'd like is:
>
> 1) On write, assert when a writeRequired element is missing.
>
> 2) On read, when a writeRequired element is missing, fill in a default  
> value.

What do you mean by assert? Treat is as an error? Also, if the document
is going to be fixed on read, the only reason to also verify it on write
would be if the application logic can modify it so that it does not
conform to the new vocabulary version (normally, without generating
default c-tors, this won't be possible). Or am I missing something?


> I was hoping it could be as simple as something like this:
>
> <xsd:compledType name="MyType">
>   ...
> </xsd:compledType>
>
> <!-- default value for writeRequired MyType elements -->
> <xsd:element name="MyTypeDefault" type="MyType">
>   ...
> </xsd:element>
>
> <xsd:complexType> name="SomeOtherType">
>   <xsd:sequence>
>     <xsd:element name="foo"
>                  type="MyType"
>                  minOccurs="0"
>                  xse:writeRequired="true"
>                  xse:defaultValue="MyTypeDefault"/>
>   </xsd:sequence>
> <xsd:complexType>

This won't be valid XML Schema because the MyTypeDefault declaration
would need to be able to contain arbitrary XML fragments, for example:

<xsd:element name="MyTypeDefault" type="MyType">
  <foo>foo</foo>
  <bar>
    <one>1</one> 
    <two>2</two>
    <three>3</three>
  </bar>
</xsd:element>

I think the only way to capture such information directly in XML Schema
is to use the appinfo element which allows arbitrary content, for example:

<xsd:complexTypename="SomeOtherType">
  <xsd:sequence>

    <xsd:element name="foo"
                 type="MyType"
                 minOccurs="0"
                 xse:writeRequired="true">    
      <xsd:annotation>
        <xsd:appinfo>
          <xse:defaultValue>
            <foo>foo</foo>
            <bar>
              <one>1</one> 
              <two>2</two>
              <three>3</three>
            </bar>
          </xse:defaultValue>
        <xsd:appinfo>
      </xsd:annotation>
    <xsd:element>

  </xsd:sequence>
<xsd:complexType>

This might actually be a better idea than a separate default values
file and XPath expressions.


> Whoa, you're going WAY beyond anything I had in mind. :-) Pretty cool,  
> but feels over-engineered for my purposes.

Yes, it feels a bit wild at the beginning (C++ function names in XML 
Schema). But then I try to avoid incomplete solutions since people
will keep coming back and asking why this, now "obvious", feature is
not supported ;-).


> Could it really be accomplished?

The C++ callbacks are actually very easy to implement. The custom header
with their declarations can be included using the --hxx-prologue option.

The default value part is harder mainly because of the difficulty of
initializing a static object model fragment from XML. But I think I 
have an idea. What I can do, fairly easily, is, based on the DOM 
fragment that represents the default value, generate a series of C++
calls that re-create this DOM fragment. This code can then be used
to "build up" the DOM document with fragments corresponding to the 
default values when they are missing. The nice thing about this
approach is that it will work transparently with other features such
as the DOM association. The only problem that I see so far is const-
correctness (DOMDocument and DOMElement are passed as const references
to parsing functions/c-tors).

Boris