[xsd-users] Supporting recursive types with XSD/Parser
Wood, Matthew D
matthew.d.wood at intel.com
Tue Feb 8 21:47:34 EST 2011
Thanks again for the quick response on my previous question.
I recently discovered another issue processing the XACML 2.0 schema. The <Apply/> element can be nested, such as:
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">abc</AttributeValue>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
<ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Apply>
</Condition>
I see the following set of calls using XSD/Parser w/Expat for the XML above (indented to match XML):
ConditionType_pimpl::pre()
ApplyType_pimpl::pre() // First Apply element start
ApplyType_pimpl::FunctionId()
AttributeValueType_pimpl::pre()
AttributeValueType_pimpl:: _any_characters() // xsi:anyType
AttributeValueType_pimpl::post_AttributeValueType() // via post_ExpressionType() override
ApplyType_pimpl::Expression() // result of AttributeValueType_pimpl::post_AttributeValueType()
ApplyType_pimpl::pre() // Second Apply element start
ApplyType_pimpl::FunctionId()
ActionAttributeDesignatorType_pimpl::pre()
ActionAttributeDesignatorType_pimpl::AttributeId()
ActionAttributeDesignatorType_pimpl::DataType()
ActionAttributeDesignatorType_pimpl::post_ActionAttributeDesignatorType() // via post_ExpressionType() override
ApplyType_pimpl::Expression() // result of ActionAttributeDesignatorType_pimpl::post_AttributeValueType()
ApplyType_pimpl::Expression() // !!!! same value was passed to previous call !!!!
ApplyType_pimpl::post_ApplyType() // via post_ExpressionType() override
// !!!! Missing second call to post_ApplyType() !!!!
ConditionType_pimpl::Expression() // result of ApplyType_pimpl::post_ApplyType()
ConditionType_pimpl::post_ConditionType()
Since the ApplyType_pimpl is a recursively called parser, I implemented an internal value stack. Whenever a pre() call is made, it pushes a state record. Element callbacks are handled using the state on the top of the stack. The post_ApplyType() calls cause a return value to be generated and the stack to pop. Since the callbacks aren't being called correctly, the stack never pops the second time.
I couldn't find an example of how to handle this successfully. Am I missing something, or is this a known issue? A workaround would be greatly appreciated.
Thanks in advance,
Matt
More information about the xsd-users
mailing list