[x3d-public] [x3d] [X3D] X3D schema, DTD updates: USE HAnim objects

[Don Brutzman]

thank you for the thoughtful review Joe.

On 1/22/2015 6:13 PM, Joe D Williams wrote:
>>> HAnim* nodes: cannot require @name field
>
> not a workable rule by the current HAnim standard.
>
> In DIS terms that may apply:
>
> "Multiple owners for one entity is usually nonsensical."
>
> (where entiity is a 'standard' hanim object in the hierarchy)
>
> thus USE of an named HAnim node is nonsensical:)

H-Anim Specification does require a name field in these node definitions, as you note below, so that is the guiding reference.
http://www.web3d.org/documents/specifications/19774/V1.0/HAnim/ObjectInterfaces.html

You are correct that an HAnim* USE node within an skeleton doesn't make sense.

There are specific cases called out where HAnim* USE nodes appear as direct children of HAnimHumanoid, motivated by making them accessible to IK engines etc.

X3D DTD and Schema do not quite have sufficient expressive power to make this distinction between the two cases.

X3D Schematron (and thus X3D Validator) does have sufficient expressive power to make this distinction, and will provide error messages if either USE case is handled incorrectly.  8)

I just rechecked and the X3D Specification is inconsistent about noting that name field is required, have submitted a specification comment to fix that omission:

X3D Humanoid Animation (H-Anim) component
26.3 Node reference
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/hanim.html#Nodereference

>>> - Metadata*, HAnim* nodes: cannot require @name field or else USE nodes fail to validate
>>
>> to me, that is OK.
>
> it is OK because there is no case of 'standard' humanoid where USE is valid or necessary.
>
> Besides, the spec says
> Humanoid: The name field, which shall be present, stores the name of the humanoid defined by the Humanoid object.
>
> Joint: The name field is the only field which must be defined, all the other fields are optional.
>
> Segment: The name field shall be present, so that the Segment can be distinguished from other Segment objects.
>
> SIte: The name field shall be present so that the Site can be distinguished from other Site objects.
>
> Maybe some problems come from the fact that for VRML/X3D the HAnim name sort of overlaps the DEF.
>
> Nonetheless, for 'standard' every hanim object has to have a unique name (that is actually shown in the standard).
> This makes it not proper to USE an hanim object.
> Maybe a limitation,
> maybe reality.
>
> Anyway, there is no reason to USE an HAnim node that has a name - it just isn't done or needed for our humanoid.
>
> except, that is in those useless legacy
> joints []
> segments []
> sites []
> fields of the Humanoid object, but that useage of USE are a special not very well explained cases that should be discussed.

agreed, except maybe regarding "useless legacy" - as we gain improving traction with our tool handling of HAnim models we may yet find that they are indeed useful.

> Thanks,
> Joe
>
> I hope I have good pointd for HAnim nodes, but it is just the same for Metastuffs. the names and datas of whatever is created by USE is really of no consequence since only the DEF is accessible.
>
>
>
> ----- Original Message ----- From: "Joe D Williams" <joedwil at earthlink.net>
> To: "Don Brutzman" <brutzman at nps.edu>; "X3D Graphics public mailing list" <x3d-public at web3d.org>; "X3D working group" <x3d at web3d.org>
> Sent: Tuesday, January 20, 2015 5:04 PM
> Subject: Re: [x3d] [X3D] X3D schema, DTD updates: FogCoordinate depth, X3DAppearanceNode is abstract
>
>
>>> - Metadata*, HAnim* nodes: cannot require @name field or else USE nodes fail to validate
>>
>>
>> to me, that is OK.
>> How would it be good to USE an HanimJoint node, or any other hanim. It just should not be done, like no good reason exists.
>> Except maybe to try to transform right to left?
>> No way for hanim, maybe for other creatures.
>>
>> Same for Meta. Why would I want another instance of the same meta data?
>>
>> If possible, more like USE nodes should Not be allowed with these.
>>
>> Thanks,
>> Joe
>>
>>
>>
>>
>> ----- Original Message ----- From: "Don Brutzman" <brutzman at nps.edu>
>> To: "X3D Graphics public mailing list" <x3d-public at web3d.org>; "X3D working group" <x3d at web3d.org>
>> Sent: Monday, January 19, 2015 8:02 PM
>> Subject: [x3d] [X3D] X3D schema, DTD updates: FogCoordinate depth, X3DAppearanceNode is abstract
>>
>>
>>> X3D Schema, DTD update activity:
>>>
>>> =============================================================================
>>> 18 January 2015, walmsley, brutzman
>>> - FogCoordinate depth field as type MFFloat array
>>> - X3DAppearanceNode abstract="true"
>>> - Metadata*, HAnim* nodes: cannot require @name field or else USE nodes fail to validate
>>> =============================================================================
>>>
>>> These assets can be found on the X3D Specifications: XML Schema and DOCTYPE Validation page.
>>>
>>>         http://www.web3d.org/specifications
>>>
>>> Full documentation updates have been autogenerated for the XML Schema and DOCTYPE validators.
>>>
>>> http://www.web3d.org/specifications/X3dSchemaDocumentation3.3/x3d-3.3.html
>>>
>>> http://www.web3d.org/specifications/X3dDoctypeDocumentation3.3.html
>>>
>>> The X3D Working Group also updated the X3D Graphics Standards: Specification Relationships diagram to show all major planned work.
>>>
>>> http://www.web3d.org/specifications/X3dSpecificationRelationships.png
>>> http://www.web3d.org/specifications/X3dSpecificationRelationships.pdf
>>>
>>> Changes are tested through validation regression testing of 3800+ open source X3D scenes.
>>>
>>> http://www.web3d.org/x3d/content/examples/X3dResources.html#Examples
>>>
>>> Feedback welcome, thanks for all contributions.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman