Khronos Public Bugzilla
Bug 1942 - Physics ref types and/or examples are all wrong (NCName, anyURI, SIDREF?)
Summary: Physics ref types and/or examples are all wrong (NCName, anyURI, SIDREF?)
Status: NEW
Alias: None
Product: COLLADA
Classification: Unclassified
Component: Schema (show other bugs)
Version: 1.4.1
Hardware: All All
: P3 major
Target Milestone: ---
Assignee: COLLADA Work Group email alias
QA Contact: COLLADA Work Group email alias
Depends on:
Reported: 2017-02-23 10:34 PST by Mick P.
Modified: 2017-02-23 10:34 PST (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mick P. 2017-02-23 10:34:50 PST
Looking at the Physics description it seems like there is no possible way to interpret it or produce a document that will validate against the schemas with it.

The examples in both schemas liberally use relative SIDREFs to address parts of the physics models. 

In places these SIDREFs seem to be referring to elements that are siblings. IT SHOULD ALSO be noted that the description of relative SIDREFs does not say if they are relative to the parent or the children.

In other places (<rigid_body_instance body> for example) relative SIDREFs are used that cannot be relative to any part of the document that these refs refer to. 

FURTHERMORE the types of these refs are NCName or even anyURI. NCName cannot be a SIDREF. IT would not validate. The 1.5.0 schema corrects this. Possibly accidentally.

Using NCName suggests that these are not meant to be SIDREF at all. That they should work instead like the <effect> SID references, which are not SIDREF. In that case, the names cannot be contain slashes or the leading relative period, and would have to be unique to the <physics_model> to validate. Is this the correct understanding? The examples either don't suggest as much, or were haphazardly copied into the the 1.4.1 manual from the 1.5.0 manual.

The CTS files do not include Physics examples for either schema.

Other elements, like <attachment> and <ref_attachment> mysteriously use anyURI for the types of their refs, where the examples look again like SIDREFs. It is strange to ask software to interpret a URI as a custom/internal datatype. URIs are broad, but not seemingly so broad to look like ./SomeRigidBody for example. Usually URIs are URLs. To refer to a local element a URI begins with a # tag.

What is going on here?

In fact, another example uses # instead of . but still seems to be referring to a SID in the example. Perhaps it's referring to an unseen "id" or the SID should have been "id" instead of "sid."

There is little clarity.