[x3d-public] both -children and -value or @value shouldn't be allowed
John Carlson
yottzumm at gmail.com
Sat May 28 13:39:25 PDT 2016
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>
More information about the x3d-public
mailing list