[X3D-Public] [X3D] containerField is should or must ?

[Don Brutzman]

from our book _X3D for Web Authors_  p. 24:
==========================================
Because contained nodes are themselves X3D fields of type SFNode/MFNode, the
name of the field relationship is listed in a containerField attribute. Default
containerField values for each node are correct in most cases, so overriding
containerField values is infrequent. This approach makes the X3D tagset terser,
easier to read, and less prone to error.
==========================================

point of information:  it is generally not possible to be strict about allowed
containerField values in the X3D DTD or X3D Schema.  if i recall correctly,
that is because it was difficult to do this properly with inheritance.
perhaps the legal options for each node could all be defined explicitly...
i'll look at that again.

interestingly, in the XML encoding where containerField is used, the
<field> and <fieldValue> tags provide the field names of contained
SFNode/MFNode elements which supersedes the containerField value.
Thus containerField is not needed for Script, ProtoInterface or ProtoInstance
field initialization.  Example:

<Script name="example" url='"MyScript.js"'>
	<field name="someGeometry" type="SFNode" accessType="initializeOnly">
		<Box containerField="ignoredValue"/>
	</field>
</Script>

there are a lot of containerField checks in the X3D Schematron rules:
http://www.web3d.org/x3d/tools/schematron/X3dSchematronValidityChecks.sch
http://www.web3d.org/x3d/tools/schematron/X3dSchematron.html

in general the X3D specification is pretty taciturn about specifying how
to handle errors.  this is intentional, because there are performance
and size costs associated with the detection and reporting of errors.
thus players are allowed some latitude.  Xj3D tends to be pretty strict,
others mileage may vary.  as an author i like verbose console outputs
so that problems can be detected and  fixed.  some argue that being forgiving
is better for end users and authors since errors may not be noticeable
anyway, but that cuts both ways when an unreported errors leads to
incorrect or unpredictable (and mysterious) player response.  in those
cases there is no way for an end user to know what went wrong or what
to report, leaving them to think "the scene is broken" or worse "the
player is broken" or worse yet "X3D is broken."  garbage in, garbage out.

i've seen some browsers offer strict versus lax mode as an option on
user preferences, that might be the best way to straddle this fence.
i'd recommend that default setting should be strict.

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, virtual worlds, underwater robots     http://faculty.nps.edu/brutzman