[x3d-public] Fwd: Re: More Object Model Work: indicating default component andlevel in X3DJSAIL
Don Brutzman
brutzman at nps.edu
Tue Aug 22 20:19:04 PDT 2017
OK but sorry, not fully understanding.
Each node and each component can appear in multiple profiles.
Meanwhile each node is in one unique component.
So to help understand what is blocking you, wondering what is the goal or use
case that you are trying to accomplish. Please advise.
For example, for a given profile, are you trying to determine what are the
corresponding components/levels and thus nodes/fields? Rules for such profile
requirements can be found in X3D Schematron, and might get added
programmatically to X3DJSAIL, but I don't think we've declaratively codified
profile capabilities anywhere else.
To describe those relationships, we'd have to add either
a. explicit list of allowed nodes in each profile, or
b. decorate each node with the profiles that it appears in.
Both are rather complex... Further complicating such an elaboration is the fact
that multiple levels are defined among fields, nodes, component and profile
requirements. Further, most profiles are strict supersets of each other - but
some are not (e.g. CADInterchange, Medical). So these
profile/component/level/node/field relationships are not a very straightforward
data structure to declare or maintain.
So is that what you want? If so, sounds like a somewhat difficult but worthy
challenge.
On 8/22/2017 3:46 PM, John Carlson wrote:
>
> 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>
> *From: *Don Brutzman <mailto:brutzman at nps.edu>
> *Sent: *Tuesday, August 22, 2017 12:37 PM
> *To: *John Carlson <mailto:yottzumm at gmail.com>; Roy Walmsley
> <mailto:roy.walmsley at ntlworld.com>
> *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
>
More information about the x3d-public
mailing list