[x3d-public] [x3d] Spec Comment by on 19775-1: Abstract X3D Definitions - V3.3

Sat Oct 15 10:48:10 PDT 2016

For freewrl, sure. We don't rely on containerfield too much - too onerous on upstream users - but apply it when declared, in x3d.
Q. If placing an ExternProtoInstance in a parent field, how do you 'look up its node type in X3D Schema' if the extern hasn't loaded yet? Allowing an ExternProtoInstance to declare its target containerField would solve that. Freewrl continues parsing a scene file while scheduling loading of externproto scene file in another thread, then populates Instances once loaded. Until loaded, they render like null nodes. But the parser does need to know where to put the Instances during parsing.

more..
I wouldn't explicitly require direct xmlschema use per se in the specs. A browser may read a schema to prepare an equivalent table during compiling/building. Future file syntax may not be xml. SAI access may need matchmaker functionality. So abstracting the lookup/matchmaking to a function in SAI for explicit use, and for implicit use during parsing, makes sense. Then the function may implement the lookup via hand-wrought tables, xmlschema, or xmlschema derived tables.

more..
Abstract interfaces I find interesting for Proto_II - a proposed new kind of proto. If a proto declares abstract interfaces from the specification, then in theory it shouldn't need to expose a concrete node type as its first node - its body can be opaque.
Then the Browser would treat it based on its abstract interfaces, while extra custom fields would be for routing in the scene.
For example if the Proto_II declares X3DBindable, then the browser would put it in a bindable stack (which one I don't know, or would it create a new bindable stack?) Or if it declares its a X3DTexture, the x3d parser knows which field it goes in without an ExternProtoInstance  needing to declare a containerField, or waiting its concrete type to load. 
Are there other benefits? Not sure. Not looking forward to refactoring a zillion lines of spaghetti C to try it. But it seems interesting. Maybe binary nodes written in another language? Or binary nodes that are unreadable, uncopyable, and can be bought and sold as a revenue model? IIRC Cortona could do binary nodes in ActiveX format. Freewrl can't.
Q. anything you'll miss if you take abstract type lists out of your concrete nodes?

________________________________________
From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Joe D Williams <joedwil at earthlink.net>
Sent: October 15, 2016 9:45 AM
To: x3d at web3d.org; Spec Feedback
Cc: x3d-public at web3d.org
Subject: Re: [x3d-public] [x3d] Spec Comment by on 19775-1: Abstract X3D Definitions - V3.3

> Solution: define the concept of container field in "X3D Architecture
> and base
> components" instead of "Extensible Markup Language (XML) encoding"
> (section
> 4.3.3 ), and give the default containerField value in the node
> reference
> sections of chapters 7-41 of 19775-1.

that is really nice. I an thinking the authors of VRML that is now X3D
Classic didn't need to highlight the funtionality of the wrappers too
much, because it could be treated as simple markup syntax. It just
gives the abstract name for a collection of nodes. The following node
must be in that collection or something won't work as expected.

In X3D, mainly because we continue to overlook the fact that the XML
schema is avalable anytime, at authortime and when authoring in
runtime, to look up this detail just from knowing the node name
(apriori knowledge of scene-graph semantics). Since we refuse to fully
excercise one of the main advantages of the schema during all aspects
of the user code lifecycle, we have the proliferation of
containerField. Its purpose is also to give the abstract name of the
collection of nodes to which this node must belong. Or else something
undefined might happen in authortime and probably runtime and so tthis
is an important item that needs to be checked as the scene is created
and anytime the scene is changed by insertion of deletion of nodes.

If wrong, then somebody's keyboard or script should Not have been
allowed to drop that DEFable node and its contents into that location
fo the user code or the actual current scenegraph. So if we used the
schema fully, then the rare exception(s) like <proxy> ... </proxy> as
required wrappers would again appear to be simple matters of required
checkable syntax that helps keep the things in that MFNode organized
without defaults and makes selecting or changing the proxy easier at
least in authortime. Instead, we must dig into the ideas behind
building really high speed loaders that might actually use a
generalized markup which names the abstract group of nodes to which
this node must belong to some actual advantage. In authoring, the
parent node must be able to accept this abstract node type as well as
process the following concrete node.

When considering the transformation of VRML to X3D, i think most
everyone considered the VRML markup as a "wrapper" because of course
that is what it was apparently used for and so that is how it was
first interpreted in XML. But really, to XML with schema it was only a
kind of processing instruction that sets the stage for what is next.
Authors really don't need to deal with that abstraction when they have
a schema. Now I would say a more fair representation of the original
VRML 'container' markup in XML would be like <geometry /> an empty
tag, rather than an enclosing set. So anyway, as the XML constructions
developed it was relatively easy to get rid of the generalized use of
"wrapper tags" based on author convenience factors and no loss of
validation power.

But it is really hard to get to the actually point of totally relying
on the schema for these kinds of details. Currently, we are promoting
the idea that it is OK for a node to carry around the name of the
abstract set of nodes to which it belongs. These days I must say that
is too much. As a node, I know I must have my name right out front, in
one string of legal characters with no spaces, and I know I can be
DEFed and USEd, but that is all I need to know and that is all
whomsoever the heck is up there is asking about it really needs to
know in order to figure out if I belong here or not. If you are so
concerned about my family, then that is an entirely different detail
that I do not wish to deal with here. I believe in the basics of
self-documention, but this is to much! If you up there need my family
name so much, then Go away and Look it up. You know where to look.
Just quit bugging me about how I need to broadcast my membership in
some group by actually carrying around the name of that group. .

containerField? con ,, tainer...F .. ield?
I don't got to show you no containerField.
I don't got to show you no stinkin' contatinerField!

It is with those treasured feelings that I now must go forward with a
plan that includes diposition of the above spec comment. For V3.4 or
next and 4.x or whatever, we must finally take the step. Yes, finally
we should rely on the schema to help us elimnate excess attribute
baggages and finally just drop containerField all together. An
artifact really of preXML so should be honorably retired as quickly as
possible.

An authoring system that needs the containerField is weak and not
fully using the XML schema. A runtime system that needs containerField
certainly needs to spend more time in authoritme.
Let's finally get rid of this authoring distraction once and for all.

Is there support outl there for this thrust into the guts of X3D by
composing the spec comment that causes X3D to obsolete the
containerField? .

Thanks and Best,
Joe

----- Original Message -----
From: "Spec Feedback" <spec-comment at web3d.org>
To: <x3d at web3d.org>
Sent: Saturday, October 15, 2016 1:09 AM
Subject: [x3d] Spec Comment by on 19775-1: Abstract X3D Definitions -
V3.3

> Comment on 19775-1: Abstract X3D Definitions - V3.3
> 4.4.2.2 Field semantics
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#FieldSemantics
>
> -----------------
> Subject: where the concept of containerField is defined and default
> values
> are listed
>
> Problem statement: the X3D standard is divided, among others, into a
> base
> document where all the concepts are defined, as well as each node
> type
> (ISO/IEC IS 19775-1); and different encodings, such as XML (ISO/IEC
> 19776-1),
> Classic (ISO/IEC 19776-2) and Binary (ISO/IEC 19776-3). The concept
> of
> container field is defined in 19776-1; since each node has its own
> default
> value, all nodes defined in 19775-1 are listed again in 19776-1
> section 6.2
> where the only new piece of information is the default
> containerField value,
> surrounded by some xml syntax which doesn't provide new information.
> Splitting the description of each node into two different standards
> has
> unneeded drawbacks: more difficult to understand for someone
> learning X3D,
> more difficult to use as a reference for the X3D author or
> implementer, more
> difficult to keep in sync for the standard authors. And should
> container
> fields eventually be used in non-XML encodings, a fix will be
> required
> anyway.
>
> Solution: define the concept of container field in "X3D Architecture
> and base
> components" instead of "Extensible Markup Language (XML) encoding"
> (section
> 4.3.3 ), and give the default containerField value in the node
> reference
> sections of chapters 7-41 of 19775-1.
> -----------------
>
> Submitted on Saturday, 2016,  October 15 - 1:09am
> by  (Yves Piguet )
> IP: 85.1.253.84
>
> See: http://www.web3d.org/node/1694/submission/1013
>
>
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org