[xsd-users] xsdcxx-musicxml

[Mario Lang]

Boris Kolpackov <boris at codesynthesis.com> writes:

> Mario Lang <mlang at delysid.org> writes:
>
>>  * How do I add a DOCTYPE to a serialized document?  Valid MusicXML documents
>>    sort of require a DTD to be stated.  Is there some way to tell the
>>    xsdcxx serializer (a bit like the properties class) that I want a !DOCTYPE to be
>>    generated as well?  Or do I serialize to a DOM document and somehow
>>    add the DOCTYPE later
>
> The way to do this is to create the DOM document with DOCTYPE yourself,
> then serialize the object model into it, and, finally, serialize the
> DOM document to XML.
>
> The Wiki has some sample code in the FAQ for how to to this. For the
> DOCTYPE part, look into the DOMImplementation class:
>
> https://xerces.apache.org/xerces-c/apiDocs-3/classDOMImplementation.html

Thanks!

>> While there is at least one subelement which can be a sequence as well
>> (dot), all others are just optionals.
>
> I took a look at the schema and the generated code. The first element
> in the generated code that I see that is a sequence is 'tie'. Looking
> at the schema:
>
> <xs:element name="tie" type="tie" minOccurs="0" maxOccurs="2"/>
>
> The next is 'dot':
>
> <xs:element name="dot" type="empty-placement" minOccurs="0" maxOccurs="unbounded">
>
> Then 'beam':
>
> <xs:element name="beam" type="beam" minOccurs="0" maxOccurs="8"/>
>
> Then 'notation':
>
> <xs:element name="notations" type="notations" minOccurs="0" maxOccurs="unbounded"/>
>
> I stopped here.

Sorry, I either was not clear enough, or my understanding of XML Schemas
is lacking.  Let me try to explain again why I *think* xsdcxx could do a
better job here: In MusicXML, the two elements that definitely require
content_order are <measure> and <part>.  Both elements reference the
same xs:group, which has the following structure:

<xs:sequence>
  <xs:choice minOccurs="0" maxOccurs="unbounded">
    <xs:element...>...
  </xs:choice>
</xs:sequence>

IOW, every element of <measure> or <part> is a choice, therefore, order
is clearly important.

However, the <note> element we are currently discussing has the
following basic structure:

<xs:sequence>
  <xs:choice>
    <xs:sequence>
      <xs:element name="a".../>
      <xs:element name="c".../>
      <xs:element name="d".../>
    </xs:sequence>
    <xs:sequence>
      <xs:element name="b".../>
      <xs:element name="c".../>
      <xs:element name="e".../>
    </xs:sequence>
    <xs:sequence>
      <xs:element name="c".../>
      <xs:element name="d".../>
      <xs:element name="e".../>
    </xs:sequence>
  </xs:choice>
  <xs:element.../>...
</xs:sequence>

Even though some of the elements have maxOccurs="unbounded", the final
serialization order is (IMO) unambigious.

If we added theoretical santiy checks, the serialization code would
probably look something like:

if (i->a()) {
  // serialize a
} else if (i->b()) {
  // serialize b
}

if (i->c()) {
  // serialize c
}

if (!i->b() && i->d()) {
  // serialize d
}
if (!i->a() && i->e()) {
  // serialize e
}

if (i->fghij...()) {
  // serialize rest...
}

>> Now, to fix this, I have to
>>    enable content_order for this element, which vastly complicates
>>    client code for absolutely no reason.  I basically have to find a way
>>    to re-implement accessors such that content_order is handled.
>> 
>>    1. Do you think we might be able to work on getting xsdcxx to DTRT
>>       for this particular element type?  (The relevant XSD snippet is
>>       below.)
>
> I am not sure what DTRT is in this case. To me it seems XSD correctly
> detects optional/sequence cardinalities (for the flattaned model that
> it implements).

I have a feeling that all that is missing, is to fix the "sorting" order
of the flattened structure.  Or, maybe, to detect identical elements in
a choice of sequences.  Because, in the <choice> above, <c> is *always*
required to be present, <a> and <b> are mutually exclusive, and <d> and
<e> are only allowed if one of <a> or <b> is present.  Again, to me, it
looks like the serialization order is rather unambigious from the
grammar given.  Whaat xsdcxx seems to do, is to flatten the sequences of
the coice one after another.  What I am likely looking for is a
mechanism to merge elements of a sequence inside of a choice during
flattening.  Something like this must already happen, since elements
inside of a choice of seuquences which are common to (some) sequences of
that choice are not serialized twice, as would be expected.  What is
missing to correctly serialize MusicXML, is to get the order right.

>>    2. If no, I will have to manually fix this up.  Either by writing all
>>       the content_order handling code required for this class (quite
>>       tedious), or, by manually implementing the part of the
>>       serialization code that is broken.  Second option is
>>       easier to do.  Is there actually a mechanism in xsdcxx to
>>       allow for manual override of particular implementations of
>>       the .cxx file?
>
> See the C++/Tree Mapping Customization Guide:
>
> http://wiki.codesynthesis.com/Tree/Customization_guide
>
> As well as the examples in the examples/cxx/tree/custom/ directory.

Oh, how could I have missed this.  Thanks again for guidance.

-- 
CYa,
  ⡍⠁⠗⠊⠕