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

Joe D Williams joedwil at earthlink.net
Thu Jan 22 18:13:48 PST 2015


>> 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:)

>> - 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.

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
>>
>> _______________________________________________
>> x3d mailing list
>> x3d at web3d.org
>> http://web3d.org/mailman/listinfo/x3d_web3d.org
> 




More information about the x3d-public mailing list