[x3d-public] both -children and -value or @value shouldn't be allowed

Don Brutzman brutzman at nps.edu
Sat May 28 17:32:49 PDT 2016

[thread moved to list with permission from participants]

From: Roy Walmsley <roy.walmsley at ntlworld.com>


Thanks, Don, for your observations. Yes, I agree with copying to the list.

A further thought is that when we have an SFNode field (such as -geometry and -appearance in the Shape node) there is no such content of "adding nodes". Instead, the dynamic is "set value". Adding or removing nodes only applies to an MFNode field, exemplified by the -children field of the Group node, where we also have addChildren and removeChildren inputOnly fields.

This particular discussion is limited to "field" definitions for Script and prototypes as well as "fieldValue" definitions in ProtoInstance. It is confusing to use a "-children" property for an SFNode field. While we have reasons, are they of sufficient stature to outweigh the confusion? Well worth discussion.


-----Original Message-----
From: Don Brutzman [mailto:brutzman at nps.edu]
Sent: 27 May 2016 17:49
To: Roy Walmsley; 'John Carlson'
Subject: Re: both -children and -value or @value shouldn't be allowed

[recommend we copy list due to broad relevance, is that OK?  better yet, is it OK in general for our JSON conversations?]

Confirming field definitions:

- non-node type values go in the @value attribute
- SF/MFNode-type values are contained within the -children array

When an SFNode appearing as sole member of an array, no distinction occurs in the field name, typically "children" in most cases.  This is a good thing, especially when adding/removing nodes dynamically at run time.

Related XML capabilities:
- X3D Schematron checks and reports on these issues when validating X3D content expressed in the XML encoding.
- Perhaps there is a way with key/keyref, but I haven't seen a mechanism in XML Schema that would also check such a constraint.
- XML DOCTYPE cannot do this.
- RelaxNG does have such expressive power.  Once we clear our still-pretty-length work list, it might be interesting to autogenerate such a schema from the X3D Object Model.

On 5/27/2016 1:56 AM, Roy Walmsley wrote:
> Hi John,
> First of all there is no such thing as a "-value" field. There is "-children" for a node type field and "@value" for any other field type. And you are right, at the moment I haven't made them mutually exclusive. However, I have looked into it, and I plan to do so in the auto generated schema.
> Your comments, however, raise an issue that is worth further discussion. Your field definition has the type SFNode. We specify it's content in "-children" which is of array type. This has the advantage of accommodating comments and ROUTEs. However, it doesn't match the SFNode type, which for built-in fields requires an object for the child. So, should we have, say, a "-child" or possibly a "-value" property for field to hold the single node value? Of course, we might still want to keep "-children" for comments and ROUTEs.
> Roy
> -----Original Message-----
> From: John Carlson [mailto:yottzumm at gmail.com]
> Sent: 27 May 2016 00:03
> To: Roy Walmsley; Don Brutzman
> Subject: both -children and -value or @value shouldn't be allowed
>  There may not be an issue, I just want to make sure that for Scripts, the following scenario isn’t acceptable.  Likely, it’s an issue with my prototype expander, and I am getting a schema violation—looks like -value  is getting thrown in there instead of overwriting -children
> 	     {
>                   "@name": "NavigationInfoNode",
>                   "@accessType": "initializeOnly",
>                   "@type": "SFNode",
>                   "-children": [
>                     {
>                       "#comment": "initialization node (if any) goes here"
>                     }
>                   ],
>                   "-value": [
>                     {
>                       "NavigationInfo": {
>                         "@visibilityLimit": 15
>                       }
>                     }
>                   ]
>                 },
> However, I don’t see any limitation in the schema, but I may be blind.
> John

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