[x3d-public] x3dom prototypes, extern proto
J. Scheurich
mufti11 at web.de
Mon Jul 13 08:39:33 PDT 2020
On 13.07.20 17:32, Don Brutzman wrote:
> wow you're rocking! 8)
>
> if we can clearly define spec prose, adding a rotation field probably
> makes sense. even more emphatic, i've never known what to do with the
> normal from a practical animation standpoint, where would you ROUTE
> it? can only figure that they are useful from an abstract
> visualization perspective maybe, if you ROUTE the value to a Script to
> massage it further.
>
> On 7/12/2020 12:14 PM, Andreas Plesch wrote:
>>
>> Le me share another example of an x3dom prototype showing a mix of dom
>> scripting and x3d event handling:
A complex example of PROTO and Inline usage is:
https://wdune.ourproject.org/examples/vrml_benz/kurve_benz_maximum.wrl
Maybe this is usefull for tesing ?
so long
MUFTI
>>
>> https://andreasplesch.github.io/x3dom/test/functional/proto/x3dom/dom/OnXTouchSensorChanged.html
>>
>>
>> listed in
>>
>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>>
>> The prototype is an enhanced TouchSensor which puts a little cone
>> marker at the hit point.
>>
>> Two issues came up. First, the cone marker needs a rotation to point
>> towards the hit point but the TouchSensor only delivers a hit normal.
>> So I added a custom hitRotation_changed SFRotation field to native
>> TouchSensor which is the rotation from the local Up direction to the
>> local hit normal direction. Maybe an idea for the spec., since
>> rotations tend to be more useful than normals. This could be done
>> otherwise in a script. The other issue is that the added marker ends
>> up as a sibling of the TouchSensor and is therefore by default
>> included in the list of shapes which are sensed by the TouchSensor.
>> This leads to weird feedback. In x3dom, it is easy to solve that issue
>> by using a x3dom only isPickable field, set to false. This lets the
>> marker being skipped by the TouchSensor. But in regular x3d I would
>> not immediately know how to address this problem. Is there a way ? Eg.
>> how would the Proto look like in regular X3D ?
>>
>> Ideas for improvement include adding all TouchSensor fields to the
>> Proto, using a node field for custom markers (with the cone as the
>> default value) and perhaps flashing a fading description field on
>> isOver.
>>
>> The example shows how to use dom scripts alongside x3d event routing,
>> with protos. Good to see that work pretty smoothly. Time to focus on
>> wiki writing.
>>
>> -Andreas
>>
>> On Sat, Jul 11, 2020 at 11:47 PM Andreas Plesch
>> <andreasplesch at gmail.com> wrote:
>>>
>>> For those who are interested in x3dom prototypes, I added a few more
>>> examples at the bottom of
>>>
>>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>>>
>>> These examples are about DOM manipulation of ProtoInstances, DOM
>>> events like onclick and some special x3dom dom event handlers. It
>>> seems to work reasonably well after discovering and fixing a few more
>>> bugs including a fatal one. I decided to only support the short
>>> instance syntax for DOM interaction since it is more natural and x3dom
>>> only anyways. It is also much more fun to write short syntax examples.
>>> Perhaps I can add short syntax support to the x_ite_dom bridge.
>>>
>>> https://andreasplesch.github.io/x3dom/test/functional/proto/x3dom/dom/OnXviewpointChanged.html
>>>
>>>
>>> is interesting in particular. It is a somewhat useful prototype,
>>> providing a drop in replacement for viewpoint to briefly show the
>>> description field as a fading text node, in front of the viewer. It
>>> uses the new 'visible' field (still 'render' in x3dom). It cheats a
>>> little connecting a MFString to a SFString field, for which normally a
>>> type conversion script would be needed (perhaps there should be a
>>> converter node? Or perhaps prototypes should automatically convert SF
>>> connected to MF.). On the DOM side it shows that the popular x3dom
>>> onviewpointchanged event handler still works with the new node, and
>>> how it is possible to tweak prototype behaviour to not only render the
>>> first node but also the subsequent helper node, by reaching into the
>>> innards of the prototype instance. One line suffices. Perhaps this
>>> could become a global option for ProtoInstances (a 'renderSecond'
>>> field), hm, could be easy to add and useful. Overall, the example is
>>> an interesting mashup of x3d and dom functionality.
>>>
>>> I am also thinking about an enhanced XTouchSensor prototype which
>>> would be a drop in replacement which visualizes the touched location
>>> and orientation, probably with a little cone (scale would need to be a
>>> parameter, probably).
>>>
>>> I am also starting to see that it could be useful to have a very
>>> simple X3DomScript node which would be just evaled in the browser
>>> context without fields or any checking. This would allow packaging
>>> simple dom scripts with extern protos or inlines.
>>>
>>> Since this is getting more robust and useful, the main step missing is
>>> documentation on how to use Prototypes. I will probably use the x3dom
>>> github wiki for a short introduction, using the two color table as an
>>> example.
>>>
>>> Any feedback as always much appreciated,
>>>
>>> -Andreas
>>>
>>> On Tue, Jun 30, 2020 at 10:44 PM Andreas Plesch
>>> <andreasplesch at gmail.com> wrote:
>>>>
>>>> Hi John,
>>>>
>>>> I have grabbed the json protoexpander disabling commenting and added a
>>>> few json examples to
>>>>
>>>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>>>>
>>>>
>>>> as well as the short protoinstance syntax ones. I discovered another,
>>>> obscure issue with those but will not fix it for now.
>>>>
>>>> I also cleaned and split up the code. A typical usage scenario will be
>>>> that a proto like the twocolortable will be expected to respond to dom
>>>> manipulation of the fieldvalues. I do not think this is currently
>>>> working but could be possible without too much effort and I think is
>>>> necessary. Attribute manipulation of the short syntax nodes may work
>>>> already.
>>>>
>>>> Andreas
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jun 29, 2020 at 8:36 PM John Carlson <yottzumm at gmail.com>
>>>> wrote:
>>>>>
>>>>> I don't have a good way to do a pull request since I reforked. I
>>>>> suggest we grab my latest change (1 change) in my master, and
>>>>> merge that with whatever branch you're working on. Otherwise,
>>>>> grab the zip from coderextreme.net
>>>>>
>>>>> There's currently just one example with X3DScript. I will work on
>>>>> converting over more of my examples.
>>>>>
>>>>> Just this ViewFrustum was the first one I changed. I will produce
>>>>> more robust changes, I think.
>>>>>
>>>>> Woohoo!
>>>>>
>>>>> John
>>>>>
>>>>> On Mon, Jun 29, 2020 at 7:06 PM John Carlson <yottzumm at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> I created X3DScript.js as the first attempt at adding a
>>>>>> <X3DScript> tag.
>>>>>>
>>>>>> Example (ViewFrustum) attached.
>>>>>>
>>>>>> I'm having a bit of a problem with the Viewpoint IS child. An
>>>>>> exception is being thrown.
>>>>>>
>>>>>> Andreas, you don't need to solve any script problems, unless you
>>>>>> want to figure out why the url isn't being set.
>>>>>>
>>>>>> I have an eval where I think the url loading is appropriate for
>>>>>> now. We may want to move script loading somewhere else.
>>>>>>
>>>>>> I don't currently handle embedded scripts. That will require
>>>>>> more thinking.
>>>>>>
>>>>>> I hope you can find this code in X3DOM. I have commented with ///
>>>>>> where the issue is
>>>>>>
>>>>>> //find node type from IS in body
>>>>>> var ISRoutes = that._protoBody._ISRoutes;
>>>>>> var ISconnection = ISRoutes[ field.name
>>>>>> ][ 0 ];
>>>>>> var nodeField = ISconnection.nodeField;
>>>>>> var ISDomNode =
>>>>>> that._protoBody.querySelector( "[DEF=" + ISconnection.nodeDEF +
>>>>>> "]" );
>>>>>> //create temp node to get type
>>>>>> var type = x3dom.nodeTypes.X3DNode;
>>>>>> var IStype =
>>>>>> ISDomNode.localName.toLowerCase();
>>>>>> if ( IStype in x3dom.nodeTypesLC )
>>>>>> {
>>>>>> var ISNode = new x3dom.nodeTypesLC[
>>>>>> IStype ]( ctx );
>>>>>> type = ISNode._cf[ nodeField
>>>>>> ].type; /// Can't handle nodeField === "ViewpointNode"
>>>>>> }
>>>>>>
>>>>>> zip link below with start of X3DScript.js and data files, and
>>>>>> package file in x3dom.
>>>>>>
>>>>>> I think this is the IS that's failing:
>>>>>>
>>>>>> <IS>
>>>>>> <connect nodeField='visible' protoField='visible'/>
>>>>>> <connect nodeField='ViewpointNode'
>>>>>> protoField='ViewpointNode'/>
>>>>>> <connect nodeField='NavigationInfoNode'
>>>>>> protoField='NavigationInfoNode'/>
>>>>>> <connect nodeField='aspectRatio'
>>>>>> protoField='aspectRatio'/>
>>>>>> <connect nodeField='trace' protoField='trace'/>
>>>>>> </IS>
>>>>>>
>>>>>> Could it be that a trailing "ode" on the fields is throwing
>>>>>> things off? IDK.
>>>>>>
>>>>>> http://coderextreme.net/script.zip
>>>>>>
>>>>>> It will take me a while to recreate my x3dom repo, so you can
>>>>>> diff my x3dom code. I will do that next.
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On Mon, Jun 29, 2020 at 5:41 PM Andreas Plesch
>>>>>> <andreasplesch at gmail.com> wrote:
>>>>>>>
>>>>>>> Yes, the view frustum example requires a script.
>>>>>>>
>>>>>>> I have added the t1 example (and found the t.wrl inline) to
>>>>>>>
>>>>>>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>>>>>>>
>>>>>>>
>>>>>>> It worked fine.
>>>>>>>
>>>>>>> I another folder, I converted all examples to the non-standard
>>>>>>> concise
>>>>>>> proto instance node syntax which x3dom will support:
>>>>>>>
>>>>>>> <TwoColorTable legColor="1 0 0" topColor="0 1 0"></TwoColorTable>
>>>>>>>
>>>>>>> https://andreasplesch.github.io/x3dom/test/functional/proto/x3dom.htm
>>>>>>>
>>>>>>>
>>>>>>> Take a look at the x3d code below the viewer.
>>>>>>>
>>>>>>> I discovered one issue doing that which could be resolved. I
>>>>>>> think all
>>>>>>> examples work with that more concise syntax. containerField
>>>>>>> hints for
>>>>>>> node values may be necessary in cases.
>>>>>>>
>>>>>>> Any feedback or non-script examples are still very welcome.
>>>>>>>
>>>>>>> -Andreas
>>>>>>>
>>>>>>> On Mon, Jun 29, 2020 at 3:28 PM John Carlson
>>>>>>> <yottzumm at gmail.com> wrote:
>>>>>>>>
>>>>>>>> I think I concluded that the ViewFrustum (proto3.html) example
>>>>>>>> required a script.
>>>>>>>>
>>>>>>>> On Mon, Jun 29, 2020 at 2:26 PM John Carlson
>>>>>>>> <yottzumm at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Here's another example which I couldn't really get right in
>>>>>>>>> X3DOM.
>>>>>>>>>
>>>>>>>>> https://coderextreme.net/X3DJSONLD/src/main/html/proto3.html
>>>>>>>>>
>>>>>>>>> Works okay in X_ITE.
>>>>>>>>>
>>>>>>>>> On Mon, Jun 29, 2020 at 2:01 PM John Carlson
>>>>>>>>> <yottzumm at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> I am fairly sure:
>>>>>>>>>>
>>>>>>>>>> <component name='Networking' level='2'/>
>>>>>>>>>>
>>>>>>>>>> Is required for t1.x3d.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Jun 29, 2020 at 1:42 PM John Carlson
>>>>>>>>>> <yottzumm at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Here's a link that shows essentially the same results
>>>>>>>>>>> between X_ITE and X3DOM. The spheres are much smaller now?
>>>>>>>>>>>
>>>>>>>>>>> https://coderextreme.net/X3DJSONLD/src/main/html/proto2.html
>>>>>>>>>>>
>>>>>>>>>>> Thanks for double checking!
>>>>>>>>>>>
>>>>>>>>>>> Go ahead and close the x3dom issue 1044 issue once you check
>>>>>>>>>>> in your changes. I will probably refork my repo, since I
>>>>>>>>>>> overwrote my master.
>>>>>>>>>>>
>>>>>>>>>>> John
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jun 29, 2020 at 12:10 PM John Carlson
>>>>>>>>>>> <yottzumm at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Here's the issue I was unable to solve in 36 hours of
>>>>>>>>>>>> debugging, still related to protos.
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/x3dom/x3dom/issues/1044
>>>>>>>>>>>>
>>>>>>>>>>>> I should be able to provide a data file, t1.x3d, if necessary.
>>>>>>>>>>>>
>>>>>>>>>>>> John
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jun 29, 2020 at 11:11 AM John Carlson
>>>>>>>>>>>> <yottzumm at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> How does one handle scripts inside a ProtoBody (multiple
>>>>>>>>>>>>> instances of the same script) is what next on our (or just
>>>>>>>>>>>>> my) plate.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jun 29, 2020 at 11:04 AM Andreas Plesch
>>>>>>>>>>>>> <andreasplesch at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nothing is done to script elements. So the ones with a
>>>>>>>>>>>>>> vrmlscript ( or
>>>>>>>>>>>>>> any non html standard ) mime type are ignored, and
>>>>>>>>>>>>>> regular script
>>>>>>>>>>>>>> elements executed by the browser as dom scripts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Andreas
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jun 29, 2020 at 11:57 AM John Carlson
>>>>>>>>>>>>>> <yottzumm at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yeah! Andreas! Once you clean up, I will attempt to
>>>>>>>>>>>>>>> add some kind of internal scripting to X3DOM. I’m
>>>>>>>>>>>>>>> curious though, what do you currently do with Protos
>>>>>>>>>>>>>>> with Scripts? Where does the script go?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Jun 29, 2020 at 10:31 AM Andreas Plesch
>>>>>>>>>>>>>>> <andreasplesch at gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> After too many hours in the debugger, I added not too
>>>>>>>>>>>>>>>> many lines to
>>>>>>>>>>>>>>>> better deal with changes to node value fields, in
>>>>>>>>>>>>>>>> particular on how to
>>>>>>>>>>>>>>>> properly transfer these from the proto instance node to
>>>>>>>>>>>>>>>> the underlying
>>>>>>>>>>>>>>>> native (or other proto) node.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> rubikFurnace.x3d should work now, in parallel with the
>>>>>>>>>>>>>>>> logo letter
>>>>>>>>>>>>>>>> example which was the main challenge.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://5efa06157960e80256fa5d6b--x3dom.netlify.app/
>>>>>>>>>>>>>>>> https://5efa06157960e80256fa5d6b--x3dom.netlify.app/examples/functional/proto/inline.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I believe this concludes my substantive efforts. I will
>>>>>>>>>>>>>>>> now focus on
>>>>>>>>>>>>>>>> separating out the proto code to a new file and some
>>>>>>>>>>>>>>>> clean up.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Andreas
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sun, Jun 28, 2020 at 6:40 PM John Carlson
>>>>>>>>>>>>>>>> <yottzumm at gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I got some more time to work on this, and the new
>>>>>>>>>>>>>>>>> X3DOM proto code does just as well with JSON as it
>>>>>>>>>>>>>>>>> does for XML. Congratulations!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think if Andreas fixes the outstanding rubik*'s
>>>>>>>>>>>>>>>>> errors (hopefully this will stop the BoxEm errors),
>>>>>>>>>>>>>>>>> and the t1.json/t1.x3d error in the x3dom issues, I
>>>>>>>>>>>>>>>>> believe we can declare this successful, and we can
>>>>>>>>>>>>>>>>> move onto "scripts"--whatever we're going to call the
>>>>>>>>>>>>>>>>> new script node, if not Script. If someone has a
>>>>>>>>>>>>>>>>> document on how X3DOM routes work (especially with
>>>>>>>>>>>>>>>>> namescopes), that will help me help with scripts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm not checking in my X3DJSONLD proto expander
>>>>>>>>>>>>>>>>> disabling code for now. For now, my copy will remain
>>>>>>>>>>>>>>>>> disabled for testing.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There are errors to the X3DJSONLD console if someone
>>>>>>>>>>>>>>>>> wants me to copy and paste.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If you want me to check in code for this into
>>>>>>>>>>>>>>>>> x3dom/andreasplesch's gh-pages branch, let me know. I
>>>>>>>>>>>>>>>>> only made change to the PrototypeExpander.js code,
>>>>>>>>>>>>>>>>> which effectively disabled the JSON proto expander,
>>>>>>>>>>>>>>>>> see below patch (patch to package.json unnecessary).
>>>>>>>>>>>>>>>>> diff --git a/package.json b/package.json
>>>>>>>>>>>>>>>>> index e1e0d501..7043f4f5 100644
>>>>>>>>>>>>>>>>> --- a/package.json
>>>>>>>>>>>>>>>>> +++ b/package.json
>>>>>>>>>>>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>>>>>>>>>>> },
>>>>>>>>>>>>>>>>> "scripts": {
>>>>>>>>>>>>>>>>> "test": "echo \"Error: no test specified\" &&
>>>>>>>>>>>>>>>>> exit 1",
>>>>>>>>>>>>>>>>> - "build": "node ./build/src-builder.js",
>>>>>>>>>>>>>>>>> + "build": "node --trace-warnings
>>>>>>>>>>>>>>>>> ./build/src-builder.js",
>>>>>>>>>>>>>>>>> "lint": "eslint \"src/**/*.js\"",
>>>>>>>>>>>>>>>>> "lint-fix": "eslint --fix \"src/**/*.js\""
>>>>>>>>>>>>>>>>> },
>>>>>>>>>>>>>>>>> diff --git a/src/util/json/PrototypeExpander.js
>>>>>>>>>>>>>>>>> b/src/util/json/PrototypeExpander.js
>>>>>>>>>>>>>>>>> index 9bf64e6a..fc1e87e0 100644
>>>>>>>>>>>>>>>>> --- a/src/util/json/PrototypeExpander.js
>>>>>>>>>>>>>>>>> +++ b/src/util/json/PrototypeExpander.js
>>>>>>>>>>>>>>>>> @@ -740,6 +740,8 @@ x3dom.PROTOS.prototype = {
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> prototypeExpander : function ( file, object )
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> + // Use Andreas' proto code
>>>>>>>>>>>>>>>>> + /*
>>>>>>>>>>>>>>>>> this.protos = {};
>>>>>>>>>>>>>>>>> this.names = {};
>>>>>>>>>>>>>>>>> this.protoField = {};
>>>>>>>>>>>>>>>>> @@ -756,6 +758,7 @@ x3dom.PROTOS.prototype = {
>>>>>>>>>>>>>>>>> object = this.flattener( object );
>>>>>>>>>>>>>>>>> // console.error("SCRIPTS",
>>>>>>>>>>>>>>>>> JSON.stringify(this.scriptField));
>>>>>>>>>>>>>>>>> // console.error("PROTOS",
>>>>>>>>>>>>>>>>> JSON.stringify(this.protoField, null, 2));
>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>> return object;
>>>>>>>>>>>>>>>>> },
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sun, Jun 28, 2020 at 2:38 PM John Carlson
>>>>>>>>>>>>>>>>> <yottzumm at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm showing X_ITE sort of working, select
>>>>>>>>>>>>>>>>>> rubikFurnace.json on the below linked page. Perhaps
>>>>>>>>>>>>>>>>>> it's the conversion to/from JSON that makes it work?
>>>>>>>>>>>>>>>>>> Or perhaps the JSON proto expander? Turning off the
>>>>>>>>>>>>>>>>>> proto expander shows spheres for X_ITE/JSON, but
>>>>>>>>>>>>>>>>>> green cubes for X_ITE XML/DOM. It appears that
>>>>>>>>>>>>>>>>>> X_ITE/JSON/Protos/rubikFurnace needs some work which
>>>>>>>>>>>>>>>>>> X3DJSONLD/proto expander magically fixes. I usually
>>>>>>>>>>>>>>>>>> run with proto expansion enabled, so I wouldn't
>>>>>>>>>>>>>>>>>> normally catch this error! Thanks for the bug report!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://coderextreme.net/X3DJSONLD/src/main/html/index.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This uses your netlify version of x3dom.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Pasting XML into the above page with proto expansion
>>>>>>>>>>>>>>>>>> on, only the X3DOM/XML/DOM version fails. Other
>>>>>>>>>>>>>>>>>> versions show green cubes. Without the proto
>>>>>>>>>>>>>>>>>> expansion, the previous example mentioned fails, but
>>>>>>>>>>>>>>>>>> the JSON X_ITE version fails with white cubes.
>>>>>>>>>>>>>>>>>> Loading XML with a local server shows no
>>>>>>>>>>>>>>>>>> differences. I guess I could check the console
>>>>>>>>>>>>>>>>>> next. Looks okay.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> After working on t1.json for a while (see your x3dom
>>>>>>>>>>>>>>>>>> issue related to proto expander), I noticed that my
>>>>>>>>>>>>>>>>>> changes broke some of the rubik*'s examples. I was
>>>>>>>>>>>>>>>>>> not successful at making both t1.json and rubik.json
>>>>>>>>>>>>>>>>>> working. I don't know if that helps or not. Making
>>>>>>>>>>>>>>>>>> the .x3d versions of these examples work may be tricky.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am following your lead on renaming "sphere" to
>>>>>>>>>>>>>>>>>> "sphereproto" in rubik.x3d
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I will start testing with your netlify version:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Here is my proto check page with netlify (all
>>>>>>>>>>>>>>>>>> examples seem to work, json proto expander on):
>>>>>>>>>>>>>>>>>> http://coderextreme.net/X3DJSONLD/src/main/html/x3domproto.html
>>>>>>>>>>>>>>>>>> for JSON.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Here's the equivalent for XML Inlines (please try to
>>>>>>>>>>>>>>>>>> get this page or similar working like the previous!)
>>>>>>>>>>>>>>>>>> with netlify.
>>>>>>>>>>>>>>>>>> https://coderextreme.net/X3DJSONLD/src/main/html/xmlproto.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The two files should be checked into github for your
>>>>>>>>>>>>>>>>>> editing convenience.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The xmlproto.html is much better with a locally built
>>>>>>>>>>>>>>>>>> x3dom (gh-pages branch) than the remote netlify
>>>>>>>>>>>>>>>>>> version. You might want to update the netlify version?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Note the presence of a Script in the flowerproto.
>>>>>>>>>>>>>>>>>> I'm not expecting that to work yet. It might be fun
>>>>>>>>>>>>>>>>>> to get it working, though, which I have kind of done:
>>>>>>>>>>>>>>>>>> https://coderextreme.net/X3DJSONLD/src/main/html/proto.html
>>>>>>>>>>>>>>>>>> (select ../data/x3domflowers.x3d).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If you've got a script instance per flower from your
>>>>>>>>>>>>>>>>>> proto implementation, it might be possible. One just
>>>>>>>>>>>>>>>>>> needs to rename "scripts"/implement the routes to and
>>>>>>>>>>>>>>>>>> from "scripts" (whatever you want to call them), I am
>>>>>>>>>>>>>>>>>> pretty sure. This becomes more and more doable, I am
>>>>>>>>>>>>>>>>>> thinking now, thanks to your effort with Protos.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Don, can you add a check to the X3dToJson.xslt to
>>>>>>>>>>>>>>>>>> throw a warning if a proto declare name is the same
>>>>>>>>>>>>>>>>>> as a tag?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Sun, Jun 28, 2020 at 12:28 AM Andreas Plesch
>>>>>>>>>>>>>>>>>> <andreasplesch at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks, very helpful. Two issues came up. Since
>>>>>>>>>>>>>>>>>>> 'sphere' is a name of
>>>>>>>>>>>>>>>>>>> a regular node, but then was registered as a new
>>>>>>>>>>>>>>>>>>> proto node, things
>>>>>>>>>>>>>>>>>>> broke. Not sure what to do about it, maybe just
>>>>>>>>>>>>>>>>>>> documenting. HTML has
>>>>>>>>>>>>>>>>>>> a requirement for names of custom nodes to avoid
>>>>>>>>>>>>>>>>>>> such conflicts. I
>>>>>>>>>>>>>>>>>>> renamed the proto to protosphere which fixed the
>>>>>>>>>>>>>>>>>>> scene. rubikOnFire
>>>>>>>>>>>>>>>>>>> was interesting because it is the only example which
>>>>>>>>>>>>>>>>>>> has an IS
>>>>>>>>>>>>>>>>>>> connection to a node field of a ProtoInstance. I
>>>>>>>>>>>>>>>>>>> found a workaround
>>>>>>>>>>>>>>>>>>> which should work most of the time. rubikFurnace
>>>>>>>>>>>>>>>>>>> does not work, it
>>>>>>>>>>>>>>>>>>> shows just the default spheres, not sure. x-ite has
>>>>>>>>>>>>>>>>>>> the same problem
>>>>>>>>>>>>>>>>>>> with it, so maybe there is a deeper issue although I
>>>>>>>>>>>>>>>>>>> think the x3d
>>>>>>>>>>>>>>>>>>> looks ok.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> PS: I started to use a chromebook and I think x-ite
>>>>>>>>>>>>>>>>>>> and x3dom are the
>>>>>>>>>>>>>>>>>>> only x3d browsers for this platform. I looks like
>>>>>>>>>>>>>>>>>>> freeWrl for android
>>>>>>>>>>>>>>>>>>> would need to be updated to work on it. I am getting
>>>>>>>>>>>>>>>>>>> used to the
>>>>>>>>>>>>>>>>>>> touchscreen,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Sat, Jun 27, 2020 at 9:38 PM John Carlson
>>>>>>>>>>>>>>>>>>> <yottzumm at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Here is an example to try:
>>>>>>>>>>>>>>>>>>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/data/rubik.x3d
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Other rubik*.x3d examples in same folder may be
>>>>>>>>>>>>>>>>>>>> useful too, but I can no longer remember all the
>>>>>>>>>>>>>>>>>>>> differences. I know all shapes should be the same
>>>>>>>>>>>>>>>>>>>> in the result, cylinder results are not correct and
>>>>>>>>>>>>>>>>>>>> there are 27 shapes in the result.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The result of the one in the email should be 27
>>>>>>>>>>>>>>>>>>>> spheres.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Sat, Jun 27, 2020 at 6:23 PM Andreas Plesch
>>>>>>>>>>>>>>>>>>>> <andreasplesch at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I also start to think the main reason for the
>>>>>>>>>>>>>>>>>>>>> ExternProto fields is to
>>>>>>>>>>>>>>>>>>>>> enable easier and more performant loading by
>>>>>>>>>>>>>>>>>>>>> browsers, using a
>>>>>>>>>>>>>>>>>>>>> template and fill in the details later approach.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I expanded my working example list to a
>>>>>>>>>>>>>>>>>>>>> satisfactory number for x3dom
>>>>>>>>>>>>>>>>>>>>> and will start to clean up and refactor a bit.
>>>>>>>>>>>>>>>>>>>>> Almost each example
>>>>>>>>>>>>>>>>>>>>> needed additional attention to the processing so
>>>>>>>>>>>>>>>>>>>>> no doubt there are
>>>>>>>>>>>>>>>>>>>>> gaps in coverage which soon will be discovered by
>>>>>>>>>>>>>>>>>>>>> actual usage. But as
>>>>>>>>>>>>>>>>>>>>> long as the complexity in terms of nesting and
>>>>>>>>>>>>>>>>>>>>> async. loading does not
>>>>>>>>>>>>>>>>>>>>> exceed the examples, the behaviour should be
>>>>>>>>>>>>>>>>>>>>> fairly robust. The #name
>>>>>>>>>>>>>>>>>>>>> syntax works. The helicopter (Example16) is fairly
>>>>>>>>>>>>>>>>>>>>> complex and works
>>>>>>>>>>>>>>>>>>>>> now, after replacing the script with event
>>>>>>>>>>>>>>>>>>>>> utilities. The LogoLetter
>>>>>>>>>>>>>>>>>>>>> example unearthed another interesting bug which
>>>>>>>>>>>>>>>>>>>>> triggered exponential
>>>>>>>>>>>>>>>>>>>>> doubling of shapes. Some castle engine examples
>>>>>>>>>>>>>>>>>>>>> stress the limits,
>>>>>>>>>>>>>>>>>>>>> mostly by redefining DEFs (usually a no go) but do
>>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>>> reasonable now.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The approach taken is to register actual new node
>>>>>>>>>>>>>>>>>>>>> types (which
>>>>>>>>>>>>>>>>>>>>> internally use other nodes) and then use more or
>>>>>>>>>>>>>>>>>>>>> less the regular node
>>>>>>>>>>>>>>>>>>>>> creation and instancing for the ProtoInstances,
>>>>>>>>>>>>>>>>>>>>> after converting them
>>>>>>>>>>>>>>>>>>>>> to a more readable syntax. I think this works as
>>>>>>>>>>>>>>>>>>>>> well as expanding
>>>>>>>>>>>>>>>>>>>>> templates and feels more natural but tends to
>>>>>>>>>>>>>>>>>>>>> uncover implicit
>>>>>>>>>>>>>>>>>>>>> assumptions in the code. For example, x3dom
>>>>>>>>>>>>>>>>>>>>> assumes that Material as a
>>>>>>>>>>>>>>>>>>>>> X3DAppearanceChild node is always a child of an
>>>>>>>>>>>>>>>>>>>>> Appearance node. With
>>>>>>>>>>>>>>>>>>>>> protos, it can be a child of another node as well.
>>>>>>>>>>>>>>>>>>>>> So I had to
>>>>>>>>>>>>>>>>>>>>> eventually start to use a try/catch clause.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks for maintaining the example, they are
>>>>>>>>>>>>>>>>>>>>> critical to get uniform behaviours.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Here are the updated working examples:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I may be interested in trying a few more examples
>>>>>>>>>>>>>>>>>>>>> without script nodes
>>>>>>>>>>>>>>>>>>>>> but I think these are a good selection.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any feedback welcome,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -Andreas
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Jun 26, 2020 at 2:09 PM Don Brutzman
>>>>>>>>>>>>>>>>>>>>> <brutzman at nps.edu> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 6/26/2020 10:50 AM, Andreas Plesch wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks for thinking this through. I am not
>>>>>>>>>>>>>>>>>>>>>>> seeing any inconsistencies,
>>>>>>>>>>>>>>>>>>>>>>> only redundancies which could invite authoring
>>>>>>>>>>>>>>>>>>>>>>> errors in the first
>>>>>>>>>>>>>>>>>>>>>>> place.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I think for now, x3dom will have to go by the
>>>>>>>>>>>>>>>>>>>>>>> garbage in, garbage out
>>>>>>>>>>>>>>>>>>>>>>> principle, meaning that inconsistent field
>>>>>>>>>>>>>>>>>>>>>>> statements may cause
>>>>>>>>>>>>>>>>>>>>>>> problems. The spec. actually requires consistent
>>>>>>>>>>>>>>>>>>>>>>> naming.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> agreed
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jun 26, 2020 at 10:06 AM Don Brutzman
>>>>>>>>>>>>>>>>>>>>>>> <brutzman at nps.edu> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Checking ProtoDeclare and ExternProtoDeclare
>>>>>>>>>>>>>>>>>>>>>>>> can be tricky, but I think it is correctly
>>>>>>>>>>>>>>>>>>>>>>>> defined.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> My understanding of the intent of that section
>>>>>>>>>>>>>>>>>>>>>>>> was to prevent unexpected errors in the case of
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> a. ProtoDeclare defined,
>>>>>>>>>>>>>>>>>>>>>>>> b. ExternProtoDeclare and ProtoInstance example
>>>>>>>>>>>>>>>>>>>>>>>> work and are deployed,
>>>>>>>>>>>>>>>>>>>>>>>> c. ProtoDeclare subsequently adds some
>>>>>>>>>>>>>>>>>>>>>>>> additional fields or changes default field values,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> How would that happen ? Externally, by editing
>>>>>>>>>>>>>>>>>>>>>>> the ProtoDeclare in the
>>>>>>>>>>>>>>>>>>>>>>> referenced file ? That would seem like a
>>>>>>>>>>>>>>>>>>>>>>> situation which should not be
>>>>>>>>>>>>>>>>>>>>>>> in the scope of x3d.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> correct. have seen this occur with long-term
>>>>>>>>>>>>>>>>>>>>>> re-use of valuable prototypes that continue to
>>>>>>>>>>>>>>>>>>>>>> evolve, it is important to find external
>>>>>>>>>>>>>>>>>>>>>> instances or modify/evolve them with backwards
>>>>>>>>>>>>>>>>>>>>>> compatibility in mind.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> d. ExternProtoDeclare and ProtoInstance example
>>>>>>>>>>>>>>>>>>>>>>>> still work OK though new ProtoDeclare is
>>>>>>>>>>>>>>>>>>>>>>>> retrieved at runtime.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hm, is there a requirement to reload already
>>>>>>>>>>>>>>>>>>>>>>> loaded ProtoDeclare's
>>>>>>>>>>>>>>>>>>>>>>> when a new ProtoInstance is added to a scene ?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> no, that would be dangerous/unexpected. no hidden
>>>>>>>>>>>>>>>>>>>>>> dependencies here, just stepping through typical
>>>>>>>>>>>>>>>>>>>>>> use.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Certainly the browser loading the
>>>>>>>>>>>>>>>>>>>>>>>> original/updated ProtoDeclare must honor the
>>>>>>>>>>>>>>>>>>>>>>>> behavior defined therein, including default
>>>>>>>>>>>>>>>>>>>>>>>> values.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If the field interfaces within the
>>>>>>>>>>>>>>>>>>>>>>>> ExternProtoDeclare (which only contain name,
>>>>>>>>>>>>>>>>>>>>>>>> type, accessType and not default values) are
>>>>>>>>>>>>>>>>>>>>>>>> different, that would be an error.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> yes, exactly, so why have those field interfaces ?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Having ExternProtoDeclare allows a browser to
>>>>>>>>>>>>>>>>>>>>>> load and set up all connections with type
>>>>>>>>>>>>>>>>>>>>>> information in mind, allowing remote loading of
>>>>>>>>>>>>>>>>>>>>>> ProtoDeclare to occur in parallel. Thus
>>>>>>>>>>>>>>>>>>>>>> performance speedup.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> As above, if default values within the
>>>>>>>>>>>>>>>>>>>>>>>> ProtoDeclare change, this has no impact on
>>>>>>>>>>>>>>>>>>>>>>>> ExternProtoDeclare field definitions because
>>>>>>>>>>>>>>>>>>>>>>>> they do not list default values.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I am not sure how the default values could change.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> long-term evolution of a published prototype in a
>>>>>>>>>>>>>>>>>>>>>> library, for example.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> When a ProtoInstance provides fieldValue
>>>>>>>>>>>>>>>>>>>>>>>> initializations, they of course supersede
>>>>>>>>>>>>>>>>>>>>>>>> whatever the default might be in the ProtoDeclare.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> ... so I think this all hangs together cleanly
>>>>>>>>>>>>>>>>>>>>>>>> without contradiction or ambiguity.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Agreed, just potentially confusing redundancy.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> it takes some practice to get familiar since the
>>>>>>>>>>>>>>>>>>>>>> capabilities are powerful.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Implementation-support notes:
>>>>>>>>>>>>>>>>>>>>>>>> - InstantReality handles cases well, although
>>>>>>>>>>>>>>>>>>>>>>>> console warnings sometimes include false
>>>>>>>>>>>>>>>>>>>>>>>> positives.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I am using view3dscene and freeWrl for testing.
>>>>>>>>>>>>>>>>>>>>>>> Most examples work
>>>>>>>>>>>>>>>>>>>>>>> well though freeWrl seems to have a problem with
>>>>>>>>>>>>>>>>>>>>>>> the nested spin group
>>>>>>>>>>>>>>>>>>>>>>> prototype example.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> As an author I avoid nested prototypes, they seem
>>>>>>>>>>>>>>>>>>>>>> less robust and more likely to fail.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - X3D-Edit has a feature to check
>>>>>>>>>>>>>>>>>>>>>>>> ExternProtoDeclare interfaces against
>>>>>>>>>>>>>>>>>>>>>>>> ProtoDeclare interfaces.
>>>>>>>>>>>>>>>>>>>>>>>> - Utility methods for such checking would be a
>>>>>>>>>>>>>>>>>>>>>>>> good feature to add to our Java, Python and
>>>>>>>>>>>>>>>>>>>>>>>> JavaScript libraries.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Loading and checking for such consistency is
>>>>>>>>>>>>>>>>>>>>>>>> typically not performed by any of our Quality
>>>>>>>>>>>>>>>>>>>>>>>> Assurance (QA) tools since they tend to perform
>>>>>>>>>>>>>>>>>>>>>>>> validations in an offline manner. For X3DOM, I
>>>>>>>>>>>>>>>>>>>>>>>> think this gap in testing coverage means that
>>>>>>>>>>>>>>>>>>>>>>>> you should carefully check for consistency
>>>>>>>>>>>>>>>>>>>>>>>> because if ProtoDeclare and ExternProtoDeclare
>>>>>>>>>>>>>>>>>>>>>>>> differ then an incompatible interface is
>>>>>>>>>>>>>>>>>>>>>>>> expected and model errors are likely.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Improvements always welcome. Thanks for close
>>>>>>>>>>>>>>>>>>>>>>>> scrutiny and thanks for tackling this super
>>>>>>>>>>>>>>>>>>>>>>>> valuable capability for X3DOM.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You can follow progress here:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html#Front
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> impressive setup
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It will be interesting to see how Protos can be
>>>>>>>>>>>>>>>>>>>>>>> used in combination
>>>>>>>>>>>>>>>>>>>>>>> with web js based templating.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -Andreas
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> thanks for taking the time to get this part right
>>>>>>>>>>>>>>>>>>>>>> now. that will make future HTML5-X3D4 patterns a
>>>>>>>>>>>>>>>>>>>>>> lot more stable and understandable.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 6/23/2020 6:10 PM, Andreas Plesch wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>>>>>> The next step would be to support the
>>>>>>>>>>>>>>>>>>>>>>>>>> ExternProtoDeclare statement.
>>>>>>>>>>>>>>>>>>>>>>>>>> The main question I have is about the
>>>>>>>>>>>>>>>>>>>>>>>>>> function of the additional field
>>>>>>>>>>>>>>>>>>>>>>>>>> statements under ExternProtoDeclare.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> - Do they replace ProtoInterface field
>>>>>>>>>>>>>>>>>>>>>>>>>> statements ? (No.)
>>>>>>>>>>>>>>>>>>>>>>>>>> - Is the ProtoInterface element still
>>>>>>>>>>>>>>>>>>>>>>>>>> required in the external file ? (Yes.)
>>>>>>>>>>>>>>>>>>>>>>>>>> - Are they listed just for convenience (for
>>>>>>>>>>>>>>>>>>>>>>>>>> the author and the browser) ? (Yes?)
>>>>>>>>>>>>>>>>>>>>>>>>>> - Can they be ignored ? (Yes?)
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I did find the clause "The names and types of
>>>>>>>>>>>>>>>>>>>>>>>>> the fields of the
>>>>>>>>>>>>>>>>>>>>>>>>> interface declaration shall be a subset of
>>>>>>>>>>>>>>>>>>>>>>>>> those defined in the
>>>>>>>>>>>>>>>>>>>>>>>>> implementation." in 4.4.5.2 EXTERNPROTO
>>>>>>>>>>>>>>>>>>>>>>>>> interface semantics. This
>>>>>>>>>>>>>>>>>>>>>>>>> means that an ExternProto can restrict access
>>>>>>>>>>>>>>>>>>>>>>>>> to fields by not listing
>>>>>>>>>>>>>>>>>>>>>>>>> them in its field elements. So they should not
>>>>>>>>>>>>>>>>>>>>>>>>> be ignored. On the
>>>>>>>>>>>>>>>>>>>>>>>>> other hand a browser which ignores them would
>>>>>>>>>>>>>>>>>>>>>>>>> still generate the same
>>>>>>>>>>>>>>>>>>>>>>>>> behaviour, minus warnings or errors in an
>>>>>>>>>>>>>>>>>>>>>>>>> ill-constructed scene when a
>>>>>>>>>>>>>>>>>>>>>>>>> ProtoInstance is trying to set non-accessible
>>>>>>>>>>>>>>>>>>>>>>>>> fields.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So I think as a first cut, it is ok to just
>>>>>>>>>>>>>>>>>>>>>>>>> load the external
>>>>>>>>>>>>>>>>>>>>>>>>> Protodeclaration and give it the name of the
>>>>>>>>>>>>>>>>>>>>>>>>> ExternProto and not doing
>>>>>>>>>>>>>>>>>>>>>>>>> much or anything with the field elements.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for any insight,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> -Andreas
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Andreas Plesch
>>>>>>>>>>>>>>>>>>>>> Waltham, MA 02453
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> x3d-public mailing list
>>>>>>>>>>>>>>>>>>>>> x3d-public at web3d.org
>>>>>>>>>>>>>>>>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Andreas Plesch
>>>>>>>>>>>>>>>>>>> Waltham, MA 02453
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Andreas Plesch
>>>>>>>>>>>>>>>> Waltham, MA 02453
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Andreas Plesch
>>>>>>>>>>>>>> Waltham, MA 02453
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Andreas Plesch
>>>>>>> Waltham, MA 02453
>>>>
>>>>
>>>>
>>>> --
>>>> Andreas Plesch
>>>> Waltham, MA 02453
>>>
>>>
>>>
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453
>>
>>
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>>
>
> all the best, Don
More information about the x3d-public
mailing list