[x3d-public] Finding more than one use of a DEF in VRML -encoding/language portability

[Joseph D Williams]

> It's important to note that this thread is mainly about DEF in VRML. Which may have different behavior than DEF in XML and JSON.   

If DEFs have any different behavior in any encoding it is an error. Please notice how the DEFs are used in vrml as a name for a reusable node component and a target.
XML id is only a element identifier or a target. 
Only one DEF or ID string is legal, although as Don pointed out, in general html, the browser may pass dup id strings and just use the first or maybey the last one if the string is referenced. No x3d should allow duplicate DEFs.
Joe



From: John Carlson
Sent: Thursday, March 26, 2020 1:25 PM
To: Don Brutzman; Leonard Daly
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] Finding more than one use of a DEF in VRML -encoding/language portability

unique DEFs for each protoexpanded ProtoBody means unique nodes in routes.  Which means unique nodes in Scripts. Which mean protoexpansion comes before routes comes before scripts.

On Thu, Mar 26, 2020 at 3:21 PM John Carlson <yottzumm at gmail.com> wrote:
PrototypeExpander needs unique DEFs for routes to work right, I believe.

On Thu, Mar 26, 2020 at 3:17 PM John Carlson <yottzumm at gmail.com> wrote:
Can Leonard update his blog entry based on the various threads?

https://realism.com/blog/defuse-x3d-vs-dom 

I think the important thing to get across is:

DEFs with duplicate field value may be duplicated within a scope (VRML).
DEFs with duplicate attribute value may not be duplicated within a scope (XML, HTML).
I'm not really sure what the JSON requirements are, but someone should probably go over the working draft.

Thanks,

John 

On Thu, Mar 26, 2020 at 2:42 PM Don Brutzman <brutzman at nps.edu> wrote:
Excellent question:

On 3/26/2020 10:49 AM, John Carlson wrote:
> It's important to note that this thread is mainly about DEF in VRML. Which may have different behavior than DEF in XML and JSON.   Do I have the whole story now, or is VRML dependent on XML types?

The X3D Architecture defines baseline information for model rendering/behavior/interaction, regardless of how that model is saved.

The various file encodings (ClassicVRML XML JSON Binary) and programming-language bindings (EcmaScript Java Python C/C#/C++ etc.) are expected to have equivalent expressive power to define an X3D model.  Other "non-standard" alternatives (TypeScript ObjectPascal etc.) should strive to follow the same path if consistent use is desired.

Thus conversion or even "round trip" between any of the forms is expected to include all of the necessary information in the X3D model.

Thus any time we find functional or expressive differences between ClassicVRML or XML or JSON or whatever, it is a deficiency and we should fix it.

As we continue to succeed well on this challenge, X3D models become fully portable and consistent regardless of where they come from and where they go.

Once again, with feeling: Have fun with X3D!  8)

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200326/98f03bf9/attachment.html>