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

[John Carlson]

Yes, it’s okay to copy the list.  I am starting to work through issues with the prototype expander.  If I run across something that seems undoable, I will report it.  For example, I reported an array inside an array not being acceptable.  I will try to revisit this.  I am making the code complex to handle either @value and -children (seems like needless complexity).  I don’t know what to do if both appear yet, so I’m going to hope that I can run the schema against the JSON before I run the prototype expander on it to catch such problems.

John
> On May 27, 2016, at 12:49 PM, Don Brutzman <brutzman at nps.edu> wrote:
> 
> [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 <mailto: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 <http://faculty.nps.edu/brutzman>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160528/e0e8fc1c/attachment-0001.html>