[x3d-public] Topics for Discussion at JSON meeting: SFNode/MFNode field/fieldValue content - MetadataSet is similar
John Carlson
yottzumm at gmail.com
Wed Feb 24 16:02:03 PST 2016
> On Feb 24, 2016, at 6:39 PM, Don Brutzman <brutzman at nps.edu> wrote:
>
> Roy thanks for looking at this. There appear to be some possible inconsistencies however we go on this one. For example, a MetadataSet at top level of ProtoBody will have a "-children" key above it; similar for field/fieldValue initialization.
>
> I'm OK to stick with "-value" rather than "-children" and certainly support the strong reasons you provided. Certainly MetadataSet is typically containerField="metadata" or containerField="value" when it appears elsewhere in the scene graph.
>
> John hopefully you are OK with that choice too?
>
As far as I know I just look at the ‘-‘ in the loader. The loader is going through massive changes though and these may affect it. It remains to be determined how much these containerFields affect appearance, I think they appear in processing more and the execution engine. There may be some things in the proto expander which depend on a longer string though. I am okay with it. Metadata is new to me. I will need some examples to go from, and how if at all, the appearance is affected. All this said, will containerFields appear as attributes in JSON or will I need to put them there for the conversion to DOM or XML? What is the rule for putting containerFields in XML attributes from the JSON? If there’s a rule I need to create, then now’s a good time to discuss it.
> Confirming JSON implications: MetadataSet can contain, in any order,
> - one "-metadata" key for its own self-referential metadata
> - one "-value" key for zero-to-many Metadata* nodes
> - one "-children" key for immediate contained comments
>
> To get this to work again in the conversion stylesheet, I had to remove 2 clauses for treating "-children" similarly, lines looking like
>
> preceding-sibling::*[$parentName = 'MetadataSet'][$fieldName = 'children'] |
>
> This likely also bears on the open issue about whether to allow Metadata* nodes as top-level children of the Scene root.
>
> I refactored the attached example to only allow Metadata* nodes with containerField='metadata' or containerField='value'. Hence none of them are at the root any more, they are all contained within MetadataSet inside a root WorldInfo.
>
> JSON converter works OK on this one, have refreshed and checked the rest of the examples, they mostly look OK to me. Confirmation welcome.
>
> Aha, found a new problem: ProtoInstance is not included in Schema as an allowed child of MetadataSet. Test scene is
> http://www.web3d.org/x3d/content/examples/Basic/development/SchemaTest.x3d <http://www.web3d.org/x3d/content/examples/Basic/development/SchemaTest.x3d>
>
> To get this modified correctly in X3D XML Schema, I think we
> - do not add ProtoInstance into ChildContentModelCore, has too many ripple side effects
> - instead add ProtoInstance as a part of a choice, together with ChildContentModelCore, all within MetadataSet
>
> Meanwhile DTD/DOCTYPE is OK, MetadataSet allows ProtoInstance children:
> http://www.web3d.org/specifications/X3dDoctypeDocumentation3.3.html#MetadataSet <http://www.web3d.org/specifications/X3dDoctypeDocumentation3.3.html#MetadataSet>
>
> So... maybe we should meet Thursday (as we usually do Thursdays, instead of cancelling this week) to discuss this further. Your call.
>
> If possible it would also be good to finally resolve whether Metadata nodes can be at top-level under Scene, presumably this also relates to your Metadata object model mantis issue.
>
> Anyway here is candidate modified schema construct for MetadataSet:
>
> <xs:element name="MetadataSet">
> <xs:annotation>
> <xs:appinfo>
> <xs:element name="value" type="MFNode" fixed="inputOutputField" default="X3DMetadataObject"/>
> <xs:element name="metadata" type="SFNode" fixed="inputOutputField" default="X3DMetadataObject"/>
> <xs:attribute name="additionalInterface" type="xs:string" default="X3DMetadataObject"/>
> <xs:attribute name="componentName" type="xs:NMTOKEN" fixed="Core"/>
> <xs:attribute name="componentLevel" type="xs:positiveInteger" fixed="1"/>
> </xs:appinfo>
> <xs:documentation source="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#MetadataSet <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#MetadataSet>"/>
> </xs:annotation>
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="IS" minOccurs="0"/>
> <xs:choice>
> <xs:group ref="ChildContentModelCore" minOccurs="0" maxOccurs="unbounded"/>
> <xs:element ref="ProtoInstance" minOccurs="0"/>
> </xs:choice>
> </xs:sequence>
> <xs:attributeGroup ref="DEF_USE"/>
> <xs:attributeGroup ref="globalAttributes"/>
> <xs:attribute name="name" type="SFString"/>
> <xs:attribute name="reference" type="SFString"/>
> <xs:attribute name="containerField" type="xs:NMTOKEN" default="metadata">
> <xs:annotation>
> <xs:appinfo>Default containerField='metadata' when providing information about the parent element itself, otherwise apply containerField='value' when this element contains payload metadata inside a parent/ancestor MetadataSet element.</xs:appinfo>
> </xs:annotation>
> </xs:attribute>
> <!-- TODO: both X3DMetadataObject and MetadataSet need to allow optional child Metadata nodes, so child model content has to be combined to avoid collisions. -->
> <!-- TODO: see X3DMetadataObject definition for potential change to X3DMetadataNode. -->
> </xs:complexType>
> </xs:element>
>
>
>
> On 2/24/2016 11:29 AM, Roy Walmsley wrote:
>> 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
> --
> 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
> <MetadataExamples.html><MetadataExamples.json><MetadataExamples.x3d>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160224/2e52be88/attachment-0001.html>
More information about the x3d-public
mailing list