[xsd-users] A9 regression

[Chris Gagneraud]

On 7 November 2016 at 13:37, Chris Gagneraud <chgans at googlemail.com> wrote:
> On 5 November 2016 at 02:52, Boris Kolpackov <boris at codesynthesis.com> wrote:
>> Hi Chris,
>>
>> Chris Gagneraud <chgans at googlemail.com> writes:
>>
>>> Using xsd-cxx version A9 on Windows, I have some issues with the error
>>> handlers, exceptions and schema validation.
>>
>> While there is a lot of information in your email, I am having a hard
>> time following what you have done and what exactly does not work.
>> Can you therefore do the following:
>>
>> 1. Read through Section 3.3, "Error Handling":
>>
>>    http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#3.3
>>
>> 2. Adjust the hello example to match your application.
>
> Unfortunately I cannot reproduce! :(
>
> So let me reformulate my question:
>
> How is it possible that with this simple code:
> try
> {
>     xml_schema::Properties props;
>     props.schema_location ("http://webstds.ipc.org/2581", "IPC-2581B_V3.0.xsd");
>     unique_ptr<IPC_2581Type> ipc(iPC_2581(argv[1], 0, props));
> }
> catch (const xml_schema::Exception& e)
> {
>     cerr << e << endl;
> }
>
> While parsing a possibly non-compliant XML file, I have this error message:
> expected element 'http://webstds.ipc.org/2581#StandardPrimitive'
>
> Instead of the usual one with line/column numbers, eg:
> test-3_r2.xml:1234:12: expected element
> 'http://webstds.ipc.org/2581#StandardPrimitive'
>
> Without knowing the line number, it's nearly impossible for me to
> track down what the problem is and how to fix it.

OK, answering myself, there's no line number, because this is thrown
by the generated code, * after the DOM parsing *, at which point the
input context is gone...

Now, the error i get is not due to the input file being
non-conformant, but by the generated code that doesn't seem to cope
with substitution groups.

My XSD makes heavy use of substitution groups, with abstract elements, eg:
+ <xsd:element name="Feature" abstract="true"/>
 |-+ <xsd:element name="UserShape" abstract="true" substitutionGroup="Feature"/>
 |   |-- <xsd:element name="UserPrimitiveRef"
type="UserPrimitiveRefType" substitutionGroup="UserShape"/>
 |   |-+ <xsd:element name="UserPrimitive" abstract="true"
substitutionGroup="UserShape"/>
 |      |-- <xsd:element name="Text" type="TextType"
substitutionGroup="UserPrimitive"/>
 |      |-- More concrete UserPrimitive sub-types
 |      |
 |-+<xsd:element name="StandardShape" abstract="true"
substitutionGroup="Feature"/>
    |--<xsd:element name="StandardPrimitiveRef"
type="StandardPrimitiveRefType" substitutionGroup="StandardShape"/>
    |-+<xsd:element name="StandardPrimitive" abstract="true"
substitutionGroup="StandardShape"/>
       |-- <xsd:element name="Hexagon" type="HexagonType"
substitutionGroup="StandardPrimitive"/>
       |-- More concrete StandardPrimitive sub-types
       |

For some reason the generated code expect an element named
"StandardPrimitive" instead of checking for all the allowed substitute
names...

The code was generated using
xsd cxx-tree \
  --root-element IPC-2581 \
  --generate-polymorphic \
  --type-naming ucc \
  --function-naming lcc \
  --namespace-map http://webstds.ipc.org/2581=ipc2581 \
  --std c++11 \
  --file-per-type --output-dir xsdtree \
  $XSD.xsd

I have tried adding several '--polymorphic-type <Type>' but it didn't
make any difference.
It seems to me that xsdcxx doesn't support "pure abstract" element
(element with "abstract='true'" but with no type),
Chris



>
> Chris
>
>
>>
>> 3. Reproduce the problem using this modified hello example.
>>
>> 4. Send the modified hello example along with the steps to reproduce the
>>    problem and what the problem is (e.g., expected the callback to be
>>    called but it was not, etc).
>>
>> Boris