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

Tue Dec 6 09:19:48 PST 2016

On 12/6/2016 3:19 AM, Yves Piguet wrote:
> Thanks, Roy.

Again thank you for your thoughtful comments Yves.

Great to see that this discussion is on the x3d-public list.  These are important points that deserve sharing, archiving and further consideration.  As you might expect, this helps us be responsive to everyone and build broader understanding.  Frequently such openness also leads to new ideas and further improvements as well - the X3D community is critically important.

I've intermingled your prior post and Roy's response a bit to facilitate adding a few more points.

>> On 6 Dec 2016, at 11:39, Roy Walmsley <roy.walmsley at ntlworld.com> wrote:
> Hi Yves,
>
> Thank you for your comments. You made five, which I will respond to.
>
> _ _
>
> 1)      _“connect” only listed within “IS”_: Was it intentional?  It wasn’t intentional to not list it separately. However, it is only used by IS. But where is it in the abstract specification 19775-1? Hadn’t noticed before, but I’m not finding it. This seems to be an omission that needs rectification. Thanks for drawing attention to this topic.

+1

	X3D Abstract Specification
	4.4.4.3 PROTO definition semantics
	http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#PROTOdefinitionsemantics

> 2)      _JSON is planned for 19776 Part 5_: Will there be a Part 4? Yes, a part 4 was planned first, although it has been overtaken in terms of progress by JSON. Part 4 was planned to be the Efficient Binary Encoding. See http://www.web3d.org/specifications/X3dSpecificationRelationships.png.

Yes, we expect that encodings Part 4 will be Efficient Binary Encoding (EBE).  Please see

	Web3D Consortium Standards Strategy
	http://www.web3d.org/strategy

Roy, am also noticing we don't seem to have a page to link the corresponding language binding 19777-3? there.  Might the efforts on that challenge now be far enough along to summarize?  Just wondering.  (Our work list remains pretty long -- help is always welcome!)

	* X3D C++/C# Language Binding.
	New support for X3D Scene Access Interface (SAI) using C++/C# programming languages.

>> 3)      Use of the distinct prefixes “@” and “-“: I’ll let Don answer this one more fully.

Excellent question.  Please see two documents, multiple sections, for descriptions about where this encoding landed.

	http://www.web3d.org/wiki/index.php/X3D_JSON_Encoding#Conversion_Considerations

	X3D to JSON Stylesheet Converter
	http://www.web3d.org/x3d/stylesheets/X3dToJson.html
	Data Types | Design Patterns | Design Correspondences

This design correspondence (among others) is all part of what needs to be written up formally in an ISO specification.

So Roy's excerpt is pointing us towards what will properly express this approach.

Not a dodge - this use of distinct prefixes “@” and “-“ might still be improved or further normalized.  Getting it coherently written up in specification prose will best help us all understand; further review and suggestions might yet find an even-better approach.

n.b. John Carlson's contributions and implementation efforts were also essential for developing this reconciliation of issues in the draft X3D JSON Encoding.

btw Roy, it appears that our Web3D 2016 Conference paper hasn't been saved and linked on those reference pages.  I'll have to look for it... might you have the final-submission version?  We should get it online and link it.

> Except for a closer match to the XML encoding, but I would humbly object to that: per http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Dataencodings "concrete data encodings for X3D shall conform to this abstract specification" (in ISO/IEC 19775), so peculiarities of one encoding shouldn't be inherited by another one. Or the JSON encoding should be clearly defined as a sub-encoding of the XML encoding.

Our goal remains to keep all of the file encodings and programming-language bindings functionally equivalent.  Some syntax similarities and differences are expected in all cases - so the X3D JSON encoding might be influenced but remains independent.

This same motivation is at the heart of our current work on X3D Object Model.

Am thinking that we should ensure that this design principle is clearly expressed at the top of every specification in the X3D family of standards.

>  However, below is the section from the draft standard (which is at the stage where we are working to get approval for release to the public for review – see also comment 5)) which covers this important point :
>
> I'm not sure to understand why the distinction is important. Which ambiguity would there be with a single prefix, e.g. "@" also used for SFNode and MFNode? I understand that for a translator from json to xml encoding which doesn't understand x3d, it would be a problem; but imo it isn't a sufficient reason.
>
>> 4)      Rationale for use of prefix “@”: We tried to keep the prefix for use on fields, or properties of “statements” that are like fields. “Statements” do not get a prefix.

Agreed with Roy's description regarding where we currently stand.  It is also implemented twice (independently, both open source) and demonstrated across the full range of X3D Example Archives.

	http://www.web3d.org/x3d/content/examples/X3dResources.html#Examples

Of course such design choices always remain worth close scrutiny and review at this stage.  We want to get it right, for implementation stability and long-term archival publication of scene content.

Reconciling differences and aligning similarities between X3D Nodes and X3D statements is a key aspect of X3D Object Model design efforts.

> Since there are already unprefixed names for other parts of the json encoding, I'd rather reserve prefixes to x3d node field names. The type of "@protoField" is likely an Id, not an sfstringValue (see http://www.web3d.org/documents/specifications/19776-2/V3.3/index.html )...

Describing the various names and name scopes as string subtypes is part of current X3D Object Model effort.  For example, using XML subtypes,
- Transform, translation node and field names are strictly defined.
- DEF and USE get subtype ID/IDREF, which are NMTOKEN type with additional semantics
- Names of prototypes, fields, HAnim nodes, etc. are NMTOKEN (no spaces, restrictions on special characters)
- Some X3D rules for naming can only be checked by X3D Schematron or code (DEF before USE, independent DEF namespace within a ProtoBody, ProtoInterface/ProtoBody/IS/connect consistency, etc.)

Further considerations for naming can be found in Scene Authoring Hints

	http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#NamingConventions

>> 5)      Access to draft standard: Sorry, but the draft standard is currently only available to members. This is a requirement of the Consortium bylaws which arises because of possible IPR issues (it applies to all new drafts). There are procedures for making it public. It is hoped to do that soon.

>> Upcoming X3D Working Group review efforts include consideration of
>>
>> 	Initial working draft:  X3D JSON Encoding
>> 	ISO-IEC 19776-5 V3.3 WD1/
>> 	https://github.com/Web3DConsortium/X3D/tree/master/ISO-IEC%2019776/ISO-IEC%2019776-5/ISO-IEC%2019776-5%20V3.3
>
> 404 for non-members :(

Correct.  Public dialog during development and public review of drafts are essential parts of our approach.  Participants and Web3D Board of Directors leadership have all decided that membership is necessary for viewing and editing these draft specification documents.

Members have a trusted role since all have agreed to the Web3D IPR policy, which prohibits the knowing introduction of patented technology without prior notification.  These precautions have helped us keep VRML97 and X3D and HAnim specifications royalty free for any use.  Joining and showing support for Web3D Consortium helps others understand the fundamental value of these assets, as well as the ongoing importance of collaborative efforts to continue progress.

	http://www.web3d.org/join

	http://www.web3d.org/member-benefits

	http://www.web3d.org/sites/default/files/page/Join%20the%20Web3D%20Consortium/Web3D_IPR.pdf

Perhaps some folks on the list want to join as a holiday gift to themselves?  Ho ho ho...  8)

> I understand. It's just that not all subscribers to x3d-public can fully benefit from links sent by Don. No problem.
>
> Best,
>
> Yves

Your close scrutiny and feedback is much appreciated Yves.  Thanks for your many efforts.

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