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

[Yves Piguet]

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

> 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.
>