[x3d-public] Status of PickableGroup node in Schema V3.3: quoting MFString defaults even if a single SFString value

[Don Brutzman]

cc: x3d-public

On 5/28/2015 8:23 AM, Roy Walmsley wrote:
> Don,
>
> In the Schema the definition of the PickableGroup <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/picking.html#PickableGroup> node sets the default value of the /objectType/ field as follows:
>
> <xs:attributename="objectType"type="MFString"default="ALL"/>
>
> Shouldn’t this include the additional quotation marks, as below, as this is an MFString field?
>
> <xs:attributename="objectType"type="MFString"default='"ALL"'/>
>
> In the definition of the X3DPickableObject abstract node the same field definition (not inherited because this is the secondary inheritance) has the additional quotation marks.


Thanks for the continued deep-dive X3D Schema review on the X3D working group list, Roy.

I think the answer to your question is yes...  but before fixing this one definition, I will try to create an X3D Schema diagnostic rule that detects the problem and any other occurrences.

... that said, I have never been happy with this MFString requirement and think it provides a minimal shortcut for X3D parsers, at the direct expense of authors and content quality.  Extensive prior debate occurred on this topic, as I recall BitManagement did not want to relax their parser to accept unquoted values as a single SFString element value in an MFString array.

Simple examples:

	<PickableGroup objectType="ALL"/>
	<NavigationInfo type="NONE"/>
or
	<PickableGroup objectType='ALL'/>
	<NavigationInfo type='NONE'/>

should be allowed, rather than requiring hieroglyphic string MFString definitions such as

	<PickableGroup objectType='"ALL"'/>
	<NavigationInfo type='"NONE"'/>

Since author's intent is unambiguous in the first cases, I don't see why we insist on making the string declaration complex and error prone.

I doubt that any HTML author would be impressed by this MFString quoting arrangement.

If anyone else sees this as a worthy opportunity, then it would be good for us to add the issue as a potential X3D v4.0 improvement for future consideration.

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