[x3d-public] x3d-3.3-JSONSchema documentation available

[Yves Piguet]

Thanks for your explanations and files, Don. I'll try to make the best of them.

A quick question for the moment: in MaterialModulator.x3d at line 87, ProtoInstance has a name attribute (name='MaterialModulator'). In MaterialModulator.x3dv at line 94, there is a name field, which isn't defined explicitly. Isn't it a conversion error?

Yves

> On 7 Dec 2016, at 09:38, Don Brutzman <brutzman at nps.edu> wrote:
> 
> These kinds of analyses can certainly get fairly obscure/byzantine/difficult.
> 
> Helpful technique:  example scene to illustrate issues of interest.  That helped pull us through a lot of apparent problems, sometimes a presumed problem either didn't occur or was more properly handled a different way.
> 
> Of note is that the prefixes "-" and "@" are for child statements and child fields, respectively.  So scenes don't touch those.
> 
> Of further note is that resulting data structures are very close to VRML structures.  Variation: ProtoDeclare/ProtoInterface/field and ProtoInstance/fieldValue are closer to the XML structure y using field/fieldValue, thereby avoiding author-defined names in object keys.  Prototoype example:
> 
> 	http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/MaterialModulator.json
> 	http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/MaterialModulator.x3dv
> 	http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/MaterialModulator.x3d
> 
> btw Cobweb works fine on that prototype.  8)
> 
> 	http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/MaterialModulatorIndex.html
> 	http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/MaterialModulatorCobweb.html
> 
> 
> On 12/6/2016 3:09 PM, Yves Piguet wrote:
>> I understand the reason of a prefix (see below), but not two different prefixes. The difference between attributes and nodes is an artifact of the XML encoding which isn't required in JSON, I think. And I'd rather avoid a prefix before any fixed name defined in the X3D JSON-encoding syntax ("profile" and "version" like "encoding", for instance).
>> 
>> A prefix offers more freedom to add reserved names in the future. In the XML encoding, user-defined names are stored in attribute values, so they cannot conflict with X3D-specific names. In JSON, a prefix avoids name clashes, that's fine.
>> 
>> In the VRML Classic encoding, keywords must not be used as names, at least not as PROTO names, I guess. I was trying to find that in ISO/IEC 19776-2, without success. There is a list of keywords in Annex A, but nowhere is it stated that Id cannot be a keyword. Maybe with enough lookahead there cannot be unsolvable ambiguity, but still it doesn't look right... At one place "keywords" are qualified as "reserved", without details. Maybe with enough lookahead there cannot be unsolvable ambiguity, but still it doesn't look right... Neither Calerga VR nor Cobweb accept keywords as PROTO names.
>> 
>> But if keywords cannot be used as Id in the VRML Classic encoding, scenes valid in some encodings cannot be translated to others. Some escape mechanism to remove this restriction would be nice.
>> 
>> Yves
> 
> Getting explicit about constraints on reserved names would certainly prohibit such undesirable inconsistencies.  Good catch, it would seem that another specification comment is in order.  Needs to be applied consistently across all X3D abstract specifications, file encodings and language bindings.
> 
>>> On 6 Dec 2016, at 20:12, <yottzumm at gmail.com> <yottzumm at gmail.com> wrote:
>>> 
>>> One reason we chose the X3D way was to pull in default values.  This was not available in other translation tools from X3D XML to X3D JSON.  Don graciously did the work of translating the XML to JSON for the default values, so he got to choose the encoding. Basically, I think he future-proofed it well enough so we can use similar names for attriubutes and nodes … and using the prefixes, distinguish them.
> 
> 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