Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic xsd:any resolution #389

merged 4 commits into from Aug 16, 2016


Copy link

@anatoliykmetyuk anatoliykmetyuk commented Aug 12, 2016

I have slightly changed the solution for this, so that to avoid a dependency between scalaxb.scala and protocol.scala. Now the function to handle non-default cases is passed by the means of implicits rather than the direct access to the protocol.

From my previous PR:

Automatic resolution of xsd:any

Consider the following snippet from dml-main.xsd, which is a part of OpenOffice schemata:

  <xsd:complexType name="CT_GraphicalObjectData">
      <xsd:any minOccurs="0" maxOccurs="unbounded" processContents="strict"/>
    <xsd:attribute name="uri" type="xsd:token" use="required"/>

In a pptx presentation slide, a XML tree that represents a table goes in place of xsd:any, for example:

<a:graphicData uri="">

a:graphicData is CT_GraphicalObjectData.
Apparently, not only the CT_Table can be used there, hence xsd:any, but often the CT_Table, or a:tbl is of interest.

The problem is, ScalaXB stores xsd:any as bare scala.xml.Elem, wrapped into scalaxb.DataRecord[Any]. Perhaps this is because xsd:any doesn't carry any type information, so ScalaXB doesn't know what to bind the element to.

However, there is a way to know for sure that <a:tbl> is a CT_Table, since it is declared in the schema:

  <xsd:element name="tbl" type="CT_Table"/>

@eed3si9n eed3si9n merged commit 108d65c into eed3si9n:master Aug 16, 2016
1 check passed
@anatoliykmetyuk anatoliykmetyuk deleted the xsd-any-resolution branch Aug 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

2 participants