[xsd-users] COLLADA and URIFragmentType

[Boris Kolpackov]

Hi Kevin,

Kevin Wooten <kevin at wooten.com> writes:

> COLLADA defines the URIFragmentType, which is allowed to be only the
> fragment portion of a URI, ensuring that the reference is within the
> current document. What is the best way to resolve this fragment if I
> have created an xsd tree mapping?

Since it is an application-specific semantics implemented outside of
XML Schema mechanisms (e.g., ID/IDREF, etc), there is no out of the
box solution for this. It is not even clear to what URIFragmentType
refers to (i.e., is it something similar to (X)HTML anchor elements?).

The only way that I can think of to generically navigate such a structure
in C++/Tree mapping is to scan underlying DOM nodes (e.g., for all anchor
elements) and use "back-pointers" to C++/Tree nodes to build a map of
URIFragment's to C++/Tree nodes. Then your application can use this map.


> Secondly, is there a way to define a custom type in the xsd mapping to
> handle specific types users encounter. As an example, I would like to
> have xsd map URIFragmentType to my own C++ class where I could add a
> "resolve" function to handle my node resolution (reference to above
> question). Is this possible?

No, it is not yet possible but we are working on this. The idea is to
provide an option which will trigger generation of C++ class templates
instead of concrete classes for types defined in XML Schema. We believe
this is better than just allowing custom types for the following reason.
In your example, you don't really want to provide your own URIFragmentType
(along with parsing/serialization code, etc). What you would rather do
is take the generated URIFragmentType and inherit your own type from it
(so that you don't have to worry about parsing/serialization, etc), add
whatever extra functionality you want (like resolve function) and use
the resulting type instead of the generated URIFragmentType.

There is a drawback to this approach, however. Since we now generate
class template instead of concrete classes, one will need to provide
a suitable typedef for every type defined in XML Schema. This can be
quite a lot of types for schemas like COLLADA. We can probably generate
an initial list of typedef to facilitate this process. What do you
think?


hth,
-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060629/bf17a630/attachment.pgp