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

[Joe D Williams]

> 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