[x3d-public] Fwd: Re: More Object Model Work: indicating default component andlevel in X3DJSAIL

[John Carlson]

As I’ve told Roy, the real thing blocking me is the lack of profile to component or node information in the object model.

John

Sent from Mail for Windows 10

From: Don Brutzman
Sent: Tuesday, August 22, 2017 12:37 PM
To: John Carlson; Roy Walmsley
Subject: Re: Fwd: Re: More Object Model Work: indicating default component andlevel in X3DJSAIL

it is available in X3D Validator now... and I'm sure it is possible in X3DJSAIL.

I'll work on that code pattern further when I add per-field validation of unique level requirements, as recently described for Inline load field.

Thanks John.

On 8/21/2017 12:04 PM, John Carlson wrote:
> Specifically, is it possible to add X3DObject.isValidForProfile()?  Why or why not?
> 
> On Aug 21, 2017 1:56 PM, "John Carlson" <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
> 
>     I am more interested in profiles.   How we can support validation of profiles with the object model.   Thus we need profile -> node info and profile -> statement info.   If this is achievable through component and level, fine, tell me how to do it.
>     ---------- Forwarded message ----------
>     From: "Don Brutzman" <brutzman at nps.edu <mailto:brutzman at nps.edu>>
>     Date: Aug 21, 2017 10:55 AM
>     Subject: Re: More Object Model Work: indicating default component and level in X3DJSAIL
>     To: "John Carlson" <yottzumm at gmail.com <mailto:yottzumm at gmail.com>>
>     Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org <mailto:x3d-public at web3d.org>>, "Roy Walmsley" <roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com>>
> 
>         Component and level information from object model and schema are now included and exposed in X3DJSAIL elements.
> 
>                  X3D Java Scene Access Interface Library (X3DJSAIL)
>         http://www.web3d.org/specifications/java/X3DJSAIL.html <http://www.web3d.org/specifications/java/X3DJSAIL.html>
> 
>         On 8/21/2017 4:10 AM, John Carlson wrote:
> 
>             Levels should be able to be handled by generating alternative source code, if levels define what attributes are implemented.   We may want to support all attributes, since a level is just the minimal support.
> 
> 
>         On 8/20/2017 8:33 PM, Don Brutzman wrote:
> 
>             Lots of good thinking on future possibilities here.
>             [...]
>             Meanwhile each node definition in object model includes component and baseline level information.  Example excerpt:
> 
>                     <ConcreteNode name="Anchor">
>                        <InterfaceDefinition specificationUrl="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Anchor <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Anchor>">
>                           <componentInfo name="Networking" level="2"/>
>             [...]
> 
>             TODO:
>             a. The component info should get added as a convenience in X3DJSAIL.  Example: final String AnchorObject.COMPONENT = "Networking";
> 
> 
>         Included COMPONENT constant, also a convenience method getComponent()
> 
>             b. The level info is a bit trickier, since different attributes can be at different levels.  Needs more thought.  Level listed as above makes sense; level on a per-attribute basis seems overly complex.
> 
> 
>         Have gone ahead and added LEVEL and getComponentLevel() to expose the available information in the object model.
> 
>             c. Path to deciding on how to best handle level is to make such level checking on non-default attribute values part of node self-validation.
> 
> 
>         Example: Inline node.  Most capabilities supported at level 2, except 'load' field which is level 3.
> 
>                  Table 9.3 — Networking component support levels
>         http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#t-supportlevels <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#t-supportlevels>
> 
>         Object model information indicates lower level:
> 
>         <ConcreteNode name="Inline">
>             <InterfaceDefinition specificationUrl="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Inline <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Inline>">
>                    <componentInfo name="Networking" level="2"/>
> 
>         Nevertheless the 'load' field does include the additional information:
> 
>         <field type="SFBool"
>             accessType="inputOutput"
>             name="load"
>             default="true">
>             <componentInfo name="Networking" level="3"/>
>         </field>
> 
>         This is primarily an issue for validation testing, as an alert to authors, since an X3D player implementation may well choose to support the load field at the lower primary Networking level 2.
> 
>         Refined TODO for X3DJSAIL: add this test for per-field level checking to validate() methods wherever such deviations occur.
> 
>         all the best, Don
>         -- 
>         Don Brutzman  Naval Postgraduate School, Code USW/Br brutzman at nps.edu <mailto:brutzman at nps.edu>
>         Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 <tel:%2B1.831.656.2149>
>         X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman <http://faculty.nps.edu/brutzman>
> 


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170822/f79f850b/attachment-0001.html>