[x3d-public] Topics for Discussion at JSON meeting:SFNode/MFNode field/fieldValue content, ProtoBody, regexes
Joe D Williams
joedwil at earthlink.net
Sat Feb 6 14:41:38 PST 2016
> only be one top level node in the ProtoBody?
What is a top-level node? I didn't understand the term.
Isn't there some more X3D established name for this? root or child?
The type of the first node defines where the proto can appear in a
scene graph. The rest is just whatever it takes to complete the
structure and provide the functionality.
So, isn't is it that any field that has a DEF can be the first node in
the proto and likewise any field that can have a DEF can be 'replaced'
by an instance of a proto?
>From HAnim#VRML V2.0 utf8 eMpTyWorlds V3.29.70
PROTO Humanoid [
exposedField SFVec3f center 0 0 0
exposedField MFNode humanoidBody [ ]
exposedField MFString info [ ]
exposedField MFNode joints [ ]
exposedField SFString name ""
exposedField SFRotation rotation 0 0 1 0
exposedField SFVec3f scale 1 1 1
exposedField SFRotation scaleOrientation 0 0 1 0
exposedField MFNode segments [ ]
exposedField MFNode sites [ ]
exposedField SFVec3f translation 0 0 0
exposedField SFString version "200x"
exposedField MFNode viewpoints [ ]
field SFVec3f bboxCenter 0 0 0
field SFVec3f bboxSize -1 -1 -1
]
{
Transform {
center IS center
rotation IS rotation
scale IS scale
scaleOrientation IS scaleOrientation
translation IS translation
children [
Group {
children IS humanoidBody
}
Group {
children IS viewpoints
}
]
}
}
Thanks,
Joe
----- Original Message -----
From: "Roy Walmsley" <roy.walmsley at ntlworld.com>
To: "'Don Brutzman'" <brutzman at nps.edu>
Cc: <x3d-public at web3d.org>
Sent: Saturday, February 06, 2016 10:27 AM
Subject: Re: [x3d-public] Topics for Discussion at JSON
meeting:SFNode/MFNode field/fieldValue content, ProtoBody, regexes
> Don,
>
> Once again thanks for your further deep considerations and
> insightful comments.
>
> When you complete this full set of changes and regenerate all the
> JSON encodings of the archive examples I will ask John to retest
> with my schema.
>
> Until then, I'll just keep adding full node definitions to the
> Schema. I completed all nodes beginning with 'G' today.
>
> So, going back to the ProtoBody, and the fact that only the first
> node is used, do we want to consider specifying that there should
> only be one top level node in the ProtoBody? Yes, there could be
> other statements, such as ROUTEs, IMPORT's, etc. and comments. But
> no point in having, for example, a Script node at the top level and
> not first node. It will simply be ignored.
>
> Not sure if I can find a way to validate only the first node. I
> can't guarantee it will be the first item at the top level. There
> could be comments or IMPORTs. The easier option is to validate all
> top level items. I'll give the matter some thought, though.
>
> Regards,
>
> Roy
>
> -----Original Message-----
> From: Don Brutzman [mailto:brutzman at nps.edu]
> Sent: 06 February 2016 18:04
> To: Roy Walmsley
> Cc: x3d-public at web3d.org; 'John Carlson'
> Subject: Re: [x3d-public] Topics for Discussion at JSON meeting:
> SFNode/MFNode field/fieldValue content, ProtoBody, regexes
>
> On 2/6/2016 2:39 AM, Roy Walmsley wrote:
>> Don,
>>
>> Thanks for your in-depth considerations.
>
> Likewise thank you Roy.
>
>> The only one I would like to comment further on is that regarding
>> nodes in ProtoBody. This is my topic 3).
>>
>> I can see your argument, and, in some ways, agree. However, how
>> would that be validated? I have a ProtoBody element, to which I
>> need to assign properties. What properties should I assign. Using
>> your method I would have to assign every possible containerField
>> name, and assign the nodes that can go there. Another disadvantage
>> is that comments would be confined to the -children property,
>> losing some of the ability to be located with most of the nodes
>> they refer to.
>>
>> Using a single -children field means it is the only property I have
>> to assign. Yes, I have to add every concrete node as a possible
>> child. It also has the advantage that comments can be interspersed.
>
> Regarding comments: yes agreed, and as with other X3D encodings, a
> prototype engine needs to skip over any comments that appear before
> the first ProtoBody node.
>
> Creating a prototype that acts solely as a comment is not an allowed
> design option.
>
>> At the moment there is no easy way to validate that a ProtoInstance
>> is being used in the correct place. Validation would need to be
>> able to find the first child of the relevant ProtoBody and check
>> that it could be used in the field that calls up the ProtoInstance.
>>
>> Let's take a small example excerpt. It's not meant to be
>> meaningful, only illustrative of principles.
>>
>> <ProtoDeclare>
>> <ProtoInterface/>
>> <ProtoBody>
>> <MetadataBoolean/>
>> </ProtoBody>
>> </ProtoDeclare>
>> ....
>> <MetadataSet>
>> <ProtoInstance name="myProto" containerField="value"/>
>> </MetadataSet> ....
>> <MetadataSet>
>> <ProtoInstance name="myProto" containerField="metadata"/>
>> </MetadataSet>
>>
>> How would the JSON encoding handle the ProtoBody? Will you assign
>> it to a -metadata or a -value field?
>
> For a terse element like <MetadataBoolean/> the default
> containerField value (provided during parsing by the X3D Schema or
> X3D DTD) is what would be assigned. In this case, default
> containerField="metadata" for the Metadata* nodes.
>
> So, in the current JSON encoding that is deployed, the JSON version
> of your ProtoDeclare above would use "-metadata" as the key.
>
>> The JSON encoding of the MetadataSet and the ProtoInstance would
>> correctly assign the ProtoInstance to the appropriate field in each
>> case. So there is no loss of information if the ProtoBody assigns
>> the MetadataBoolean to a generic -children field.
>
> Aha. Really critical point, indeed the crux of the matter. What
> specifically needs to not get lost is the node type of the first
> node. Hmmm.
>
> I've been thinking that if we indeed want to move that initial node
> in the current JSON encoding, by putting the initial node at the top
> of the "-children" field, then (instead of containerField) a
> different way to identify the node-type information may be needed.
>
> That now seems overcautious though... the node type isn't indicated
> by containerField, the node type is actually indicated by the node
> name.
>
> Hmmm.... let's press on a bit further as you suggest.
>
>> Now, consider a variation.
>>
>> <ProtoDeclare>
>> <ProtoInterface/>
>> <ProtoBody>
>> <MetadataBoolean/>
>> <MetadataBoolean/>
>> </ProtoBody>
>> </ProtoDeclare>
>>
>> Now, how would you encode the ProtoBody? According to the strict
>> wording of the specification is It illegal to use this prototype in
>> a -metadata field? The first node is still legal! So the wording of
>> the specification is probably insufficient.
>>
>> Has that muddied the waters?
>
> Well, for sake of discussion, let's call the second MetadataBoolean
> a MetadataDouble instead. Slightly less muddy:
>
> <ProtoDeclare>
> <ProtoInterface/>
> <ProtoBody>
> <MetadataBoolean/>
> <MetadataDouble/>
> </ProtoBody>
> </ProtoDeclare>
>
> Using this prototype as an instance would put the MetadataBoolean as
> an active node in the scene graph, while the MetadataDouble would be
> just hanging "alongside" it in the scene graph, rather than within
> the scene graph per se... Indeed any other nodes could also appear
> alongside, these are not rendered or traversed, and simply sit over
> on the side unless activated somehow by the first node.
>
> Elaborating this notion of "straphanger" nodes along for the ride...
> From spec, as before:
>
>> 7.2.5.8 PROTO statement
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/comp
>> onents/core.html#PROTOStatement
>> (last paragraph)
>> "The <protoDefinition> consists of a list of nodes the first of
>> which is used to specify the node type for the prototype. This list
>> may instantiate other prototypes provided that the definitions of
>> the referenced prototypes precede this PROTO statement. See 4.4.4.3
>> PROTO definition semantics for details."
>
> That first specification sentence above puts no restrictions on what
> the other nodes in the list might be.
>
> btw putting a comma somewhere in that sentence couldn't hurt...
> Dick do you need a full feedback report + Mantis issue +
> teleconference agenda item to add that comma? :0
>
> Anyway, if we continue as spec suggests, we see that the lack of
> restrictions on those nodes is indeed intentional:
>
> ==================================
> 4.4.4.3 PROTO definition semantics
>
> A prototype definition consists of one or more nodes, nested PROTO
> statements, and ROUTE statements. The first node type determines how
> instantiations of the prototype can be used in an X3D file. An
> instantiation is created by filling in the parameters of the
> prototype declaration and inserting copies of the first node (and
> its scene graph) wherever the prototype instantiation occurs.
>
> EXAMPLE If the first node in the prototype definition is a Material
> node, instantiations of the prototype can be used wherever a
> Material node can be used. Any other nodes and accompanying scene
> graphs are not part of the transformation hierarchy, but may be
> referenced by ROUTE statements or Script nodes in the prototype
> definition.
> ==================================
>
> So this allows a prototype author to carry around as many invisible
> baggage nodes as they want, stashed at the top of the ProtoBody
> after the first node. It also means that we do not validate the
> nodes appearing at the top level within a ProtoBody, since any nodes
> can appear in that list of nodes without constraint.
>
> If that first node has contained content, it must be a valid scene
> subgraph. Otherwise it can't be validly plugged in elsewhere in the
> scene as a ProtoInstance.
>
> In practice, that validation-free-zone (at the top level of the
> ProtoBody) is a very good place to put Scripts, ROUTEs, and nodes
> with IS/connect that can hold ProtoInterface field initialization
> values.
>
> Illustrative examples:
>
> <ProtoDeclare name="invalid">
> <ProtoInterface/>
> <ProtoBody>
> <MetadataBoolean>
> <-- contained nodes are strictly validated, so the following
> nodes fail inside a MetadataBoolean -->
> <Script/>
> <ROUTE/>
> <ROUTE/>
> </MetadataBoolean>
> </ProtoBody>
> </ProtoDeclare>
>
> <ProtoDeclare name="valid">
> <ProtoInterface/>
> <ProtoBody>
> <MetadataBoolean/>
> <-- follow-on sibling nodes are not strictly validated at top
> level, though their children will be -->
> <Script/>
> <ROUTE/>
> <ROUTE/>
> <WorldInfo>
> <IS>
> <connect/>
> </IS>
> </WorldInfo>
> </ProtoBody>
> </ProtoDeclare>
>
> Hope that is all sensible. The abstract spec does seem pretty well
> specified on this point.
>
> At first the looseness of the ProtoBody top-level node list does
> appear unfamiliar to many authors, since we are stridently strict
> about scene-graph structure just about everywhere else. We further
> remain strict within any of the individual nodes appearing in this
> list.
>
> ... OK back to the point at hand for the JSON encoding. Can we put
> the first ProtoBody node at the top of the "-children" field,
> without loss of necessary information?
>
> I'm now convinced that you are indeed correct. It is the node name
> for the first ProtoBody node (e.g. "MetadataBoolean"), and not the
> containerField, that determines the node type of the ProtoDeclare
> being created (and corresponding ProtoInstance being instantiated in
> the scene graph).
>
> So yes let's move that first node into the "-children" array in the
> JSON encoding.
>
> Absent other considerations on this issue, I will work to implement
> and deploy this change in X3dToJson.xslt and the X3D Examples
> Archives.
>
> Again thanks for sustained scrutiny... these certainly can get deep
> at times! This is the kind of diligence that makes X3D scenes and
> X3D players reliable.
>
> p.s. status update: yesterday's change fixing the "-value" key for
> JSON encoding of contained SFNode/MFNode content in field/fieldValue
> tags is complete, fully deployed, and ready for testing.
>
>
>> -----Original Message-----
>> From: Don Brutzman [mailto:brutzman at nps.edu]
>> Sent: 06 February 2016 03:04
>> To: Roy Walmsley; John Carlson
>> Cc: x3d-public at web3d.org
>> Subject: Re: [x3d-public] Topics for Discussion at JSON meeting:
>> SFNode/MFNode field/fieldValue content, ProtoBody, regexes
>>
>> 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.
>>>>
>>>> 1) *Review of progress on JSON Schema development and validation
>>>> testing on example archive.*
>>
>> As the screen shot only began to indicate, this is really rocking!
>> as
>> discussed it will be great to
>> - autogenerate the X3D JSON Schema from the X3D Object Model
>> - include it as informative annex in future spec
>> - Document the various validation features possible/supported
>> - Generate X3D JSON Schema documentation using XML Spy (feature
>> request submitted to Altova) or another tool
>>
>> It was also totally impressive to see that John is applying X3D
>> JSON with other JavaScript libraries to good effect.
>>
>> Tweet:
>> "d3 layout orbit x3d" by John Carlson visualizes multiple example
>> scenes using new #X3D JSON encoding
>> https://twitter.com/Web3DConsortium/status/695687691308896256
>> https://www.youtube.com/watch?v=p0fMd92mu5s
>> Data-Driven Documents @d3js_org https://d3js.org
>>
>> Great visualization!
>>
>> Presumably the availability of an X3D JSON Schema will not only
>> improve scene quality but further simplify the reliable integration
>> of X3D into a variety of JavaScript frameworks.
>>
>> uh... "X3D Anywhere" anybody?!
>>
>> Further deep-dive issues follow.
>>
>>
>>>> 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/page02.ht
>>>> m
>>>> l)
>>>>
>>>> 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).
>>
>> I have applied this correction to field/fieldValue SFNode/MFNode
>> handling in X3dToJson.xslt conversion stylesheet and will deploy
>> updates to the example archives.
>>
>> Example excerpts follow, check out the differences for
>> ("index","@value") and ("coord","-value") below:
>>
>> http://www.web3d.org/x3d/content/examples/Basic/CAD/CadGeometryExternP
>> rototypes.x3d
>> http://www.web3d.org/x3d/content/examples/Basic/CAD/CadGeometryExternP
>> rototypes.json (copy attached)
>> =========================================
>> <ProtoInstance containerField='geometry' name='IndexedQuadSet'>
>> <fieldValue name='index' value='0 3 2 1 4 5 6 7 2 7 9 8 2 3 4
>> 7'/>
>> <fieldValue name='coord'>
>> <Coordinate point='-1.5 0 0 -1.5 1 -1 -.5 1 -1 -.5 0 0 0.5 0
>> 0 1.5 0 0 1.5 1 -1 0.5 1 -1 -0.5 2 -1 0.5 2 -1'/>
>> </fieldValue>
>> </ProtoInstance>
>> =========================================
>> { "ProtoInstance":
>> {
>> "@name":"IndexedQuadSet",
>> "fieldValue": [
>> {
>> "@name":"index",
>> "@value":[0,3,2,1,4,5,6,7,2,7,9,8,2,3,4,7]
>> },
>> {
>> "@name":"coord",
>> "-value":[
>> { "Coordinate":
>> {
>>
>> "@point":[-1.5,0,0,-1.5,1,-1,-0.5,1,-1,-0.5,0,0,0.5,0,0,1.5,0,0,1.5,1,-1,0.5,1,-1,-0.5,2,-1,0.5,2,-1]
>> }
>> }
>> ]
>> }
>> ]
>> }
>> }
>> =========================================
>>
>> Next issue:
>>
>>>> 3) *Encoding of node children in ProtoBody*
>>
>>>> [...snip/shuffle...]
>>>> Taking 3) above: ProtoBody can take any nodes as children. The
>>>> current converter assigns them to a field named as per the
>>>> default containerField. I propose that all nodes, irrespective of
>>>> type, be added to a /-children/ field.
>>
>> Let's think this one through a bit more, please.
>>
>> The first node in a ProtoBody has special significance, it
>> indicates the node type of the prototype being declared. This
>> language feature lets X3D authors define a prototype alternative
>> for any node in X3D - a huge extensibility feature. From the spec:
>>
>> 7.2.5.8 PROTO statement
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/comp
>> onents/core.html#PROTOStatement
>> (last paragraph)
>> "The <protoDefinition> consists of a list of nodes the first of
>> which is used to specify the node type for the prototype. This list
>> may instantiate other prototypes provided that the definitions of
>> the referenced prototypes precede this PROTO statement. See 4.4.4.3
>> PROTO definition semantics for details."
>>
>> Of note is that this is the only place in the scene graph where
>> nodes with dissimilar node types can be side by side as peers.
>>
>> In the XML encoding, the node type for the first ProtoBody child is
>> defined by it's default (or overridden) containerField value.
>>
>> In the current JSON encoding, the first node is similarly exposed,
>> and the type is the key. For example ProtoBody "-geometry" in JSON
>> encoding example below. Subsequent nodes/ROUTEs/comments all fall
>> under the "-children" key.
>>
>> I've provided abridged (but otherwise unmodified) source excerpts
>> for the examples we discussed during today's teleconference.
>>
>> [Emotional warning: this pair of examples are wonderfully or
>> horribly
>> detailed, depending on your linguistic rheostat. Our 3D
>> imaginations
>> are even bigger than the current Web, so here we go...]
>>
>> Excerpts follow.
>> http://www.web3d.org/x3d/content/examples/Basic/CAD/CadGeometryPrototy
>> pes.x3d
>> http://www.web3d.org/x3d/content/examples/Basic/CAD/CadGeometryPrototy
>> pes.json (copy attached) =========================================
>> <ProtoDeclare appinfo='The IndexedQuadSet node represents a 3D
>> shape composed of a collection of individual quadrilaterals
>> (quads). IndexedQuadSet uses the indices in its index field to
>> specify the vertices of each quad from the coord field. Each quad
>> is formed from a set of four vertices of the Coordinate node
>> identified by four consecutive indices from the index field If the
>> index field does not contain a multiple of four coordinate values
>> the remaining vertices shall be ignored.'
>> documentation='http://www.web3d.org/x3d/specifications/ISO-IEC-19775-Amendment1-PDAM-X3DAbstractSpecification/Part01/components/CADGeometry.html#IndexedQuadSet'
>> name='IndexedQuadSet'>
>> <ProtoInterface>
>> <field accessType='inputOnly' appinfo='range [0..∞) or -1'
>> name='set_index' type='MFInt32'>
>> <!-- No specific initialization value -->
>> </field>
>> <field accessType='inputOutput' appinfo='[X3DVertexAttributeNode]'
>> name='attrib' type='MFNode'>
>> <!-- Specification initialization: NULL node -->
>> </field>
>> <field accessType='inputOutput' appinfo='[X3DColorNode]'
>> name='color' type='SFNode'>
>> <!-- Specification initialization: NULL node -->
>> </field>
>> <field accessType='inputOutput' appinfo='[X3DCoordinateNode]'
>> name='coord' type='SFNode'>
>> <!-- Specification initialization: NULL node -->
>> </field>
>> <field accessType='inputOutput' appinfo='[FogCoordinate]'
>> name='fogCoord' type='SFNode'>
>> <!-- Specification initialization: NULL node -->
>> </field>
>> <field accessType='inputOutput' appinfo='[X3DNormalNode]'
>> name='normal' type='SFNode'>
>> <!-- Specification initialization: NULL node -->
>> </field>
>> <field accessType='inputOutput'
>> appinfo='[X3DTextureCoordinateNode]' name='texCoord' type='SFNode'>
>> <!-- Specification initialization: NULL node -->
>> </field>
>> <field accessType='initializeOnly' name='ccw' type='SFBool'
>> value='true'/>
>> <field accessType='initializeOnly' appinfo='colorPerVertex ignored
>> in IndexedQuadSet, and always treated as true'
>> name='colorPerVertex' type='SFBool' value='true'/>
>> <field accessType='initializeOnly' name='normalPerVertex'
>> type='SFBool' value='true'/>
>> <field accessType='initializeOnly' name='solid' type='SFBool'
>> value='true'/>
>> <field accessType='initializeOnly' appinfo='range [0..∞) or -1'
>> name='index' type='MFInt32'>
>> <!-- No specific initialization value -->
>> </field>
>> <field accessType='inputOutput' appinfo='[X3DMetadataObject]'
>> name='metadata' type='SFNode'>
>> <!-- Specification initialization: NULL node -->
>> </field>
>> </ProtoInterface>
>> <ProtoBody>
>> <IndexedFaceSet DEF='RenderedIQS'>
>> <IS>
>> <connect nodeField='attrib' protoField='attrib'/>
>> <connect nodeField='color' protoField='color'/>
>> <connect nodeField='colorPerVertex' protoField='colorPerVertex'/>
>> <connect nodeField='coord' protoField='coord'/>
>> <connect nodeField='fogCoord' protoField='fogCoord'/>
>> <connect nodeField='normal' protoField='normal'/>
>> <connect nodeField='texCoord' protoField='texCoord'/>
>> <connect nodeField='ccw' protoField='ccw'/>
>> <connect nodeField='normalPerVertex' protoField='normalPerVertex'/>
>> <connect nodeField='solid' protoField='solid'/>
>> </IS>
>> </IndexedFaceSet>
>> <!-- Initial node in the PROTO body is actual node type, and the
>> only node rendered. Remaining ProtoBody nodes not rendered -->
>> <Group DEF='UnrenderedIQS'>
>> <Script DEF='IndexedQuadSetToIndexedFaceSet' directOutput='true'>
>> <field accessType='initializeOnly' name='index' type='MFInt32'/>
>> <field accessType='inputOnly' name='set_index' type='MFInt32'/>
>> <field accessType='initializeOnly' name='renderedIQS'
>> type='SFNode'>
>> <IndexedFaceSet USE='RenderedIQS'/>
>> </field>
>> <field accessType='initializeOnly' name='localTraceEnabled'
>> type='SFBool' value='true'/>
>> <field accessType='initializeOnly' name='coordIndexNew'
>> type='MFInt32'>
>> <!-- constructed during initialization -->
>> </field>
>> <IS>
>> <connect nodeField='index' protoField='index'/>
>> <connect nodeField='set_index' protoField='set_index'/>
>> </IS>
>> <![CDATA[
>> ecmascript:
>> // [...abridged...]
>> ]]>
>> </Script>
>> <Group>
>> <MetadataString name='metadataHolder'>
>> <IS>
>> <connect nodeField='metadata' protoField='metadata'/>
>> </IS>
>> </MetadataString>
>> </Group>
>> </Group>
>> </ProtoBody>
>> </ProtoDeclare>
>> =========================================
>> { "ProtoDeclare":
>> {
>> "@name":"IndexedQuadSet",
>> "@appinfo":"The IndexedQuadSet node represents a 3D shape composed
>> of a collection of individual quadrilaterals (quads).
>> IndexedQuadSet uses the indices in its index field to specify the
>> vertices of each quad from the coord field. Each quad is formed
>> from a set of four vertices of the Coordinate node identified by
>> four consecutive indices from the index field If the index field
>> does not contain a multiple of four coordinate values the remaining
>> vertices shall be ignored.",
>> "@documentation":"http://www.web3d.org/x3d/specifications/ISO-IEC-19775-Amendment1-PDAM-X3DAbstractSpecification/Part01/components/CADGeometry.html#IndexedQuadSet",
>> "ProtoInterface": {
>> "field": [
>> {
>> "@name":"set_index",
>> "@accessType":"inputOnly",
>> "@appinfo":"range [0..∞) or -1",
>> "@type":"MFInt32",
>> "-children":[
>> { "#comment":"No specific initialization value"
>> }
>> ]
>> },
>> {
>> "@name":"attrib",
>> "@accessType":"inputOutput",
>> "@appinfo":"[X3DVertexAttributeNode]",
>> "@type":"MFNode",
>> "-children":[
>> { "#comment":"Specification initialization: NULL node"
>> }
>> ]
>> },
>> {
>> "@name":"color",
>> "@accessType":"inputOutput",
>> "@appinfo":"[X3DColorNode]",
>> "@type":"SFNode",
>> "-children":[
>> { "#comment":"Specification initialization: NULL node"
>> }
>> ]
>> },
>> {
>> "@name":"coord",
>> "@accessType":"inputOutput",
>> "@appinfo":"[X3DCoordinateNode]",
>> "@type":"SFNode",
>> "-children":[
>> { "#comment":"Specification initialization: NULL node"
>> }
>> ]
>> },
>> {
>> "@name":"fogCoord",
>> "@accessType":"inputOutput",
>> "@appinfo":"[FogCoordinate]",
>> "@type":"SFNode",
>> "-children":[
>> { "#comment":"Specification initialization: NULL node"
>> }
>> ]
>> },
>> {
>> "@name":"normal",
>> "@accessType":"inputOutput",
>> "@appinfo":"[X3DNormalNode]",
>> "@type":"SFNode",
>> "-children":[
>> { "#comment":"Specification initialization: NULL node"
>> }
>> ]
>> },
>> {
>> "@name":"texCoord",
>> "@accessType":"inputOutput",
>> "@appinfo":"[X3DTextureCoordinateNode]",
>> "@type":"SFNode",
>> "-children":[
>> { "#comment":"Specification initialization: NULL node"
>> }
>> ]
>> },
>> {
>> "@name":"ccw",
>> "@accessType":"initializeOnly",
>> "@type":"SFBool",
>> "@value":true
>> },
>> {
>> "@name":"colorPerVertex",
>> "@accessType":"initializeOnly",
>> "@appinfo":"colorPerVertex ignored in IndexedQuadSet, and always
>> treated as true",
>> "@type":"SFBool",
>> "@value":true
>> },
>> {
>> "@name":"normalPerVertex",
>> "@accessType":"initializeOnly",
>> "@type":"SFBool",
>> "@value":true
>> },
>> {
>> "@name":"solid",
>> "@accessType":"initializeOnly",
>> "@type":"SFBool",
>> "@value":true
>> },
>> {
>> "@name":"index",
>> "@accessType":"initializeOnly",
>> "@appinfo":"range [0..∞) or -1",
>> "@type":"MFInt32",
>> "-children":[
>> { "#comment":"No specific initialization value"
>> }
>> ]
>> },
>> {
>> "@name":"metadata",
>> "@accessType":"inputOutput",
>> "@appinfo":"[X3DMetadataObject]",
>> "@type":"SFNode",
>> "-children":[
>> { "#comment":"Specification initialization: NULL node"
>> }
>> ]
>> }
>> ]
>> },
>> "ProtoBody": {
>> "-geometry":[
>> { "IndexedFaceSet":
>> {
>> "@DEF":"RenderedIQS",
>> "IS": {
>> "connect": [
>> {
>> "@nodeField":"attrib",
>> "@protoField":"attrib"
>> },
>> {
>> "@nodeField":"color",
>> "@protoField":"color"
>> },
>> {
>> "@nodeField":"colorPerVertex",
>> "@protoField":"colorPerVertex"
>> },
>> {
>> "@nodeField":"coord",
>> "@protoField":"coord"
>> },
>> {
>> "@nodeField":"fogCoord",
>> "@protoField":"fogCoord"
>> },
>> {
>> "@nodeField":"normal",
>> "@protoField":"normal"
>> },
>> {
>> "@nodeField":"texCoord",
>> "@protoField":"texCoord"
>> },
>> {
>> "@nodeField":"ccw",
>> "@protoField":"ccw"
>> },
>> {
>> "@nodeField":"normalPerVertex",
>> "@protoField":"normalPerVertex"
>> },
>> {
>> "@nodeField":"solid",
>> "@protoField":"solid"
>> }
>> ]
>> }
>> }
>> }
>> ],
>> "-children":[
>> { "#comment":"Initial node in the PROTO body is actual node type,
>> and the only node rendered. Remaining ProtoBody nodes not rendered"
>> },
>> { "Group":
>> {
>> "@DEF":"UnrenderedIQS",
>> "-children":[
>> { "Script":
>> {
>> "@DEF":"IndexedQuadSetToIndexedFaceSet",
>> "@directOutput":true,
>> "field": [
>> {
>> "@name":"index",
>> "@accessType":"initializeOnly",
>> "@type":"MFInt32"
>> },
>> {
>> "@name":"set_index",
>> "@accessType":"inputOnly",
>> "@type":"MFInt32"
>> },
>> {
>> "@name":"renderedIQS",
>> "@accessType":"initializeOnly",
>> "@type":"SFNode",
>> "-value":[
>> { "IndexedFaceSet":
>> {
>> "@USE":"RenderedIQS"
>> }
>> }
>> ]
>> },
>> {
>> "@name":"localTraceEnabled",
>> "@accessType":"initializeOnly",
>> "@type":"SFBool",
>> "@value":true
>> },
>> {
>> "@name":"coordIndexNew",
>> "@accessType":"initializeOnly",
>> "@type":"MFInt32",
>> "-children":[
>> { "#comment":"constructed during initialization"
>> }
>> ]
>> }
>> ],
>> "IS": {
>> "connect": [
>> {
>> "@nodeField":"index",
>> "@protoField":"index"
>> },
>> {
>> "@nodeField":"set_index",
>> "@protoField":"set_index"
>> }
>> ]
>> },
>> "#sourceText":[ "ecmascript:","[...abridged...]" ]
>> }
>> },
>> { "Group":
>> {
>> "-metadata":[
>> { "MetadataString":
>> {
>> "@name":"metadataHolder",
>> "IS": {
>> "connect": [
>> {
>> "@nodeField":"metadata",
>> "@protoField":"metadata"
>> }
>> ]
>> }
>> }
>> }
>> ]
>> }
>> }
>> ]
>> }
>> }
>> ]
>> }
>> }
>> },
>> =========================================
>>
>> Assessment: syntax for these ProtoDeclare encodings are already
>> closely aligned with each other, and express the semantics of the
>> specification accurately.
>>
>> Recommendation: no change, enjoy! 8)
>>
>> YMMV, further insights and improvements welcome. Please advise.
>>
>>
>>>> 4) *Encoding of single value for an MFxxxxx field (non-node) -
>>>> array
>>>> or single value*
>>
>> As discussed, in previous emails and on today's call:
>> - strict typing of arrays has expressive power and matches the
>> object-oriented nature of JSON.
>> - creation of an X3D JSON Schema has the expressive power to
>> isolate problems and enforce correct typing.
>> - The appropriate rules exist already within X3dToJson.xslt
>> conversion stylesheet.
>>
>> So at this point, I simply have to go through the invalid JSON
>> scenes identified by John's JSON validation suite and fix either
>> offending .x3d content or incorrect translation details inside the
>> stylesheet.
>>
>>>> 5) *Validation of /url/ fields.*
>>
>> We discussed how JSON/javascript diagnostics (probably regex i.e.
>> regular expression based) are hiccuping on the multiple url entries
>> in X3D url MFString arrays, especially when # character is included
>> in each ProtoDeclare url.
>>
>> These are legal constructs for X3D.
>>
>> Future work: when we finish current X3D XML Schema, X3D Object
>> Model and X3D JSON work, we will return to the X3D Regular
>> Expressions effort and document correctly working regexes for X3D
>> urls.
>>
>> Skeleton page is at
>> http://www.web3d.org/specifications/X3dRegularExpressions.html
>>
>> Meanwhile: continuing bugfix attention to any invalid url content
>> detected in the X3D Examples Archives.
>>
>>>> 6)The numeric value -0.
>>
>> Further investigation in next message. This topic might seem
>> pedantic (ok ok it is very pedantic) but it is important to get
>> right from a specification perspective.
>>
>> Summary. Once again the X3D JSON design is looking pretty solid,
>> and our tool suites are pretty powerful at detecting edge-case
>> issues.
>>
>> Thanks again for steady sustained progress. Have fun with X3D JSON!
>
> 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
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
More information about the x3d-public
mailing list