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

[Roy Walmsley]

Hi all,

Following Yves original comment, and creation of Mantis issue 1055, I have
added the additional comments by Joe and Doug as Notes to the issue 1055.

Thank you all for your comments.

Regards,

Roy

-----Original Message-----
From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of doug
sanden
Sent: 15 October 2016 18:48
To: x3d-public at web3d.org
Subject: Re: [x3d-public] [x3d] Spec Comment by on 19775-1: Abstract X3D
Definitions - V3.3

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/conc
> epts.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

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