[x3d-public] [x3d] Spec Comment by walroy on 19775-1: Abstract X3D Definitions - V3.3 [Mantis 1170]
Roy Walmsley
roy.walmsley at ntlworld.com
Mon Aug 14 07:28:15 PDT 2017
Hi,
I have raised Mantis issue 1170 to cover the original comment. This is
available to Web3D members at
http://www.web3d.org/member-only/mantis/view.php?id=1170.
I have also added Don's response below as a note to this issue. It is note
2086, available at
http://www.web3d.org/member-only/mantis/view.php?id=1170#c2086.
All the best,
Roy
-----Original Message-----
From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of Don
Brutzman
Sent: 05 August 2017 18:15
To: X3D Graphics public mailing list <x3d-public at web3d.org>
Cc: x3d at web3d.org
Subject: Re: [x3d-public] [x3d] Spec Comment by walroy on 19775-1: Abstract
X3D Definitions - V3.3
[shifted to x3d-public]
Yes the abstract specification is very open-ended about such names, while
each file encoding and language bindings have their own requirements and
conventions.
Insofar as possible, we have made each encoding as broad as possible too.
But unconstrained unique strings are not always portable or advisable.
For example, in the XML encoding the XML data type for DEF/USE is ID/IDREF,
which is a uniqueness constraint applied to NMTOKEN (name token), which has
slightly different naming constraints. Simple summary at
X3D Tooltips: /type/ description
http://www.web3d.org/x3d/tooltips/X3dTooltips.html#type
For another example, few people would want whitespace as part of a DEF/USE
label because it will not be correctly parsed as such in the VRML97 or
ClassicVRML encodings.
For another example, when an X3D scene has DEF/USE that is contained in an
HTML or XML file, identical DEF names withing the primary scene and an
included ProtoDeclare ProtoBody will cause a validation failure by XML
Schema and XML DTD. I'd further expect such name collisions would cause
results to be erroneous if referred to by a DOM script.
For another (somewhat related) example, when converting scenes in X3D
Examples archive, found that hyphen - character in scene names (or
package-directory names) are undesirable because that character is a minus
sign and won't compile. Within an X3DJSAIL program, DEF/USE names
themselves can include hyphen characters, and are always validated at run
time using a regular expression for NMTOKEN:
public static final boolean isNMTOKEN(String value) {
if ((value == null) || value.trim().isEmpty())
return false;
else return value.matches("[a-zA-Z_][a-zA-Z0-9_.-]*"); // NMTOKEN
character regex check }
Perhaps we should document these various restrictions more closely as part
of author guidance... most are unavoidable but some improvement may be
possible.
We might also tighten the abstract specification to greatest common
subset... but that might not work in future encodings. Somewhat tricky
business.
As this issue occasionally comes up, a collection of best practices has
gradually been built. These are designed to allow maximum portability among
X3D representations and also best comprehension by human authors. These are
quite useful and greatly improved the interoperability of scenes in the X3D
Example Archives.
X3D Scene Authoring Hints: Naming Conventions
http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#Naming
Conventions
On 8/4/2017 8:26 AM, Spec Feedback wrote:
> -- Submitter indicates that this comment may be public: *Yes* --
>
> Comment on 19775-1: Abstract X3D Definitions - V3.3
> 4.4.3 DEF/USE semantics
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/conc
> epts.html#DEFL_USESemantics
>
> -----------------
> Subject: No general restrictions on valid DEF names
>
> Is "197_aTimer" a valid DEF name, assuming it is unique?
>
> In the abstract standard ISO/IEC 19775-1 the only restriction on node
> names is given by the following text: "Node names shall be unique in
> the context within which the associated DEF keyword occurs.". So
> according to this standard the example name is valid.
>
> In the XML encoding standard ISO/IEC 19776-1, clause 4.3.4 DEF and USE
> attribute syntax (see
> http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/conc
> epts.html#DEFAndUSEAttributeSyntax)
> the text states that "DEF is assigned XML type ID". Referring to the
> W3C XML specification, clause 3.3.1 Attribute Types (see
> https://www.w3.org/TR/REC-xml/#sec-attribute-types) states that
> "Values of type ID MUST match the Name production". The "name"
> production is defined in clause 2.3 Common Syntactic Constructs (see
> https://www.w3.org/TR/REC-xml/#sec-common-syn) where it can be seen
> that a name is not permitted to start with a digit, a "-", or a ".".
> So, we conclude that the example above is invalid.
>
> In the Classic VRML encoding standard, ISO/IEC 19776-2, clause 4.3.2.7
> Node statement syntax (see
> http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/conc
> epts.html#NodeStatementSyntax) the text gives no restrictions on
> acceptable names. Turning to the grammar at Annex A.3 Nodes (see
> http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/gram
> mar.html#Nodes) the node name is given by the production "nodeNameId",
> which, in turn, has the production "id". This production does have
> restrictions on the first character, which cannot be, inter alia, a
> digit. So, once again we conclude that the example name above is
> invalid.
>
> In the draft JSON encoding,ISO/IEC WD 19776-5, clause 4.3.2.9.1 "@DEF"
> property syntax the text simply states "The shall be any name in
> accordance with 4.4.3 DEF/USE semantics of ISO/IEC 19775-1.". Since
> the "@DEF" attribute has the property type 'string' in JSON there is
> no restriction on the first character being a digit. This also applies to
the draft JSON schema.
> Therefore, in a JSON encoded file the above example would be valid.
>
> Since the both the XML and the Classic VRML encodings have
> restrictions on valid values for names, it would be appropriate to
> detail in the abstract standard the requirements of name values to
> ensure that any given name is valid in all encodings. Not doing this
> could lead to examples that could not be round-tripped from one
> encoding to another without modifications to a DEF name.
>
> -----------------
>
> Submitted on Friday, 2017, August 4 - 4:26pm by walroy (walroy )
> IP: 82.31.58.84
>
> See: http://www.web3d.org/node/1694/submission/1416
>
>
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org
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
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
More information about the x3d-public
mailing list