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

John Carlson yottzumm at gmail.com
Tue Aug 22 21:30:07 PDT 2017


I would like to validate the contents of a JSON document against the
profile without translating to XML.   Thus profile to components or profile
to node information is required, but may be derived from what you suggest
when it will appear in the object model.

Please plan to provide this in the object model.   I believe it exists
somewhat in the XML schema.

John



On Aug 22, 2017 11:19 PM, "Don Brutzman" <brutzman at nps.edu> wrote:

> 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.w
>> eb3d.org/documents/specifications/19775-1/V3.3/Part01/
>> components/networking.html#Anchor <http://www.web3d.org/document
>> s/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.w
>> eb3d.org/documents/specifications/19775-1/V3.3/Part01/
>> components/networking.html#Inline <http://www.web3d.org/document
>> s/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/20170823/f6ade629/attachment-0001.html>


More information about the x3d-public mailing list