Khronos Public Bugzilla
Bug 169 - <bind> in kinematics and how its parents use it isn't well explained
Summary: <bind> in kinematics and how its parents use it isn't well explained
Status: NEW
Alias: None
Product: COLLADA
Classification: Unclassified
Component: Specification (show other bugs)
Version: 1.5.0
Hardware: Macintosh Mac OS
: P3 normal
Target Milestone: Release 1.5.1
Assignee: Fabrice Robinet
QA Contact: COLLADA Work Group email alias
Depends on:
Reported: 2009-05-06 16:42 PDT by Ellen Finch
Modified: 2014-01-07 10:23 PST (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ellen Finch 2009-05-06 16:42:37 PDT
1. Child element <bind>'s description in instance_articulated_system, instance_kinematics_model, motion/axis_info, and effector info should say:
"Binds a value or an existing parameter to a new symbolic name."  None of them actually say that, although a couple come close and the rest don't.

2.<bind>'s concepts section says it "maps a predefined parameter to a new symbolic name."  Shd say "maps a value or a predefined parameter to a new symbolic name."

3. <bind>'s symbol attribute says it is "The identifier of the parameter to bind to the new symbol name."  I believe that this is wrong (and confusing); I think it should be "The new symbolic name to which the specified value or parameter is bound."  Right?

4. Child elements don't say anything about what they are. Should say something like "Reference to an existing parameter to bind to the new symbolic name." or "Value to bind to...".  

5. The three value child elements should xref to the Types chapter.

6. The <SIDREF> child element says "Contains references to COLLADA scoped identifiers."  
6a. First, it contains only one such reference, not plural. 
6b. Second, it should say what kind of thing the SIDREF should refer to-- I believe it should be "Reference to the scoped identifier of an existing parameter defined using <newparam>". Right?
Comment 1 Marty Vona 2009-10-08 10:58:46 PDT
I would extend the OP's concerns to include an explanation of why kinematics bind exists at all.  If the OP is correct in saying that kinematics bind introduces a new symbolic name, then why not just use the kinematics newparam facility, which is permitted in all the same contexts?  It seems to me that if the OP is correct then newparam (plus setparam/connect_param) replicates all functionality of kinematics bind.

Another possibility is that the OP is not correct, and that kinematics bind was intended to assign a value to an existing symbolic name.  That would be more in line with bind_uniform in fx, which was previously called "bind" in 1.4, and which seems to have the same form as the present bind in 1.5 kinematics.  In this case I would ask, why do we need both bind and setparam?

Finally, there do not currently appear to be any examples in OWL of kinematics bind.