[x3d-public] Topics for Discussion at JSON meeting: SFNode/MFNode field/fieldValue content - MetadataSet is similar
Roy Walmsley
roy.walmsley at ntlworld.com
Wed Feb 24 11:29:28 PST 2016
Don,
Sorry for not latching onto this earlier.
Today, when reviewing John's latest test results, I saw that MetadataSet examples were failing to validate. I checked into why, and saw that you had assigned them to a "-children" field. So I took this out of the stylesheet, so that now they are placed into either "-metadata" or "-value", depending on the containerField setting. When I regenerated them the examples were then correctly validating. I committed the change to SourceForge.
Then you highlighted this mail to me ...
I'm sorry but I have to disagree with you on this one.
My personal opinion is that the JSON should align with the abstract specification 19775-1. In that specification MetadataSet does not have a "children" field, it has a "value" field. So a JSON encoded example should reflect the same. When we write the JSON encoding specification 19776-5 it will have to align with the abstract specification. It would be confusing to have different names for the same field in different encodings.
I can understand the inconsistency over the different uses of the field name "value". If we want to change it we should raise a specification comment and Mantis issue, then follow procedure to consider whether to implement the change, which could then be applied to all encodings.
Regards,
Roy
-----Original Message-----
From: Don Brutzman [mailto:brutzman at nps.edu]
Sent: 20 February 2016 17:39
To: John Carlson; Roy Walmsley
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] Topics for Discussion at JSON meeting: SFNode/MFNode field/fieldValue content - MetadataSet is similar
Another node that needs to be treated similarly: MetadataSet has child Metadata* nodes.
Instead of using a key "-value" the conversion now makes it "-children" for a consistent pattern with field/fieldValue content.
Example attached. Update to stylesheet is committed.
p.s. yesterday's updates (adding meta warnings to all .json files) are all uploaded.
On 2/10/2016 10:02 AM, Don Brutzman wrote:
> Followup for email thread: we chose -children (for greater
> simplicity/consistency) rather than -value
>
> On 2/8/2016 3:03 PM, John Carlson wrote:
>> I would prefer if simple type was @value, but I can change it to -value for JSON if desired.
>>
>> John
>>> On Feb 7, 2016, at 12:50 AM, Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>>>
>>> Same pattern throughout for field, fieldValue:
>>>
>>> - simple-type content goes in @value attribute for XML, "-value" key
>>> for JSON
>>>
>>> - contained node/statement/comment content is embedded in element
>>> for XML, goes in "-children" field for JSON
>>>
>>>
>>> On 2/6/2016 4:05 PM, Roy Walmsley wrote:
>>>> Don,
>>>>
>>>> I don't have any problem with that. What about for default values within a field in a ProtoInterface? Or a Shader? Or a Script?
>>>>
>>>> Roy
>>>>
>>>> -----Original Message-----
>>>> From: Don Brutzman [mailto:brutzman at nps.edu]
>>>> Sent: 06 February 2016 23:11
>>>> To: Roy Walmsley; John Carlson
>>>> Cc: x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>>>> Subject: Re: [x3d-public] Topics for Discussion at JSON meeting:
>>>> SFNode/MFNode field/fieldValue content, ProtoBody, regexes
>>>>
>>>> Testing reconsideration: using "-value" for children SFNode/MFNode content inside a fieldValue can be improved.
>>>>
>>>> Better: use "-children" instead. Common semantics, simpler encoding rules, easier to remember, less failure prone.
>>>>
>>>> Next version (test suite in progress) will use "-children" instead of "-value" for contained content.
>>>>
>>>> Test suite conversion checks appear to be performing well, update should be complete late tonite.
>>>>
>>>> Examples attached. As always, comments are welcome.
>>>>
>>>> p.s. here's one comment: i had great trouble getting "-value" to work properly. "-children" fell right into place and seems like an obvious improvement, since the earlier "-value" was an arbitrary choice.
>>>>
>>>>
>>>> On 2/5/2016 7:04 PM, Don Brutzman wrote:
>>>>> Summary: Once again the X3D JSON design is looking pretty solid, and our tool suites are pretty powerful at detecting edge-case issues.
>>>>>
>>>>> On 2/5/2016 10:37 AM, Don Brutzman wrote:
>>>>>> [correction: shifted to x3d-public] [...] On 2/4/2016 10:56 AM,
>>>>>> Roy Walmsley wrote:
>>>>>>> Topics for Discussion for JSON encoding meeting February 5^th 2016 at 1000 PST, 1800 GMT.
>>>>>>> [...]
>>>>>>> 2) *Encoding of node fields in ‘field’ and ‘fieldValue’ elements
>>>>>>> within Script and Prototypes.* [...snip/shuffle...] Illustration
>>>>>>> of
>>>>>>> 2) above is in X3D Example Archives: Basic, CAD, Cad Geometry
>>>>>>> Extern Prototypes (see
>>>>>>> http://www.web3d.org/x3d/content/examples/Basic/CAD/_pages/page0
>>>>>>> 2.ht
>>>>>>> ml)
>>>>>>>
>>>>>>> Find the ProtoInstance named ‘IndexedQuadSet’. It has two fieldValue children. The second has the name ‘coord’, and a child Coordinate node. When converted into JSON this Coordinate node is allocated to a field /-coord/, which is the default containerField name for this node. This is incorrect. It should be allocated to the /-value/ field. This is because the element fieldValue has attributes of ‘name’ and ‘value’.
>>>>>>>
>>>>>>> A similar issue arises with default values for node fields within the field element.
>>>>>
>>>>> OK this change is worth close scrutiny to avoid confusion later.
>>>>>
>>>>> For <field> and <fieldValue>, when the "@value" attribute is used for simple types, everything works OK.
>>>>>
>>>>> For <field> and <fieldValue>, with contained SFNode/MFNode content or contained comments or contained ROUTEs, the key is now "-value" (hyphen instead of ampersand).
>>>>> [...]
>>>>
>>>> Summary, revising the prior sentence:
>>>>
>>>> For <field> and <fieldValue>, with contained SFNode/MFNode content or contained comments or contained ROUTEs, the key is now "-children" as with most other child content.
>>>>
>>>> all the best, Don
>>>>
>>>
>>>
>>> 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
>>> roboticshttp://faculty.nps.edu/brutzman
>>
>
>
> all the best, Don
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