[x3d-public] X3D regexes for colorRGBA, image need work; X3DJSAIL junit5 test harness in place

Don Brutzman brutzman at nps.edu
Mon Jul 23 23:05:50 PDT 2018


On 7/23/2018 1:28 PM, Andreas Plesch wrote:
> I suppose it is necessary to look at (1.6MB of) this stylesheet:

everyday occurrence for me... 8)

> https://sourceforge.net/p/x3d/code/27143/tree/www.web3d.org/x3d/stylesheets/CreateX3dSceneAccessInterfaceJava.xslt
> 
> to see which regexes are used for the tests and how the .matches
> methods are generated ? I could not find much.

correct.   the original regexes are maintained in X3D Schema (draft versions in X3Dv4)

	http://www.web3d.org/specifications
	http://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0.html

- and then autogenerated in X3D Unified Object Model,

	http://www.web3d.org/specifications/X3DUOM.html
	http://www.web3d.org/specifications/X3dUnifiedObjectModel-4.0.xml

- and then autogenerated into X3DJSAIL via that stylesheet above,

	Package org.web3d.x3d.jsail.fields
	The fields subpackage is provided for creating typed X3D field values and also includes various utility capabilities.
	http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/fields/package-summary.html

- and also reflected on X3D Regexes page,

	http://www.web3d.org/specifications/X3dRegularExpressions.html
	http://www.web3d.org/specifications/X3dRegularExpressions.html#X3dPatterns

- and all crosslinked on X3D Tooltips page in the Field Types Table.

	http://www.web3d.org/x3d/content/X3dTooltips.html#FieldTypesTable

> The x3d regexes are intended to use within an xml context, I believe.

Actually they should work in most contexts since the XML values and VRML/ClassicVRML values and JSON values are the same.

... with one partial difference, VRML and JSON encoding include [ square brackets ] around array values, but that might well be considered as a delimiter of the encoding and not part of the value itself.

> Within an xml context, the regexes have an implicit start and end
> anchor, see:
> 
> https://www.w3.org/TR/xmlschema11-2/#regexs
> 
> where anchors are explained.
> 
> Therefore it may be necessary to add explicit start (^) and end ($)
> anchors to the start and end of each x3d regex when translating to
> jsail java methods with the stylesheet as java does not have the
> implicit anchoring.

in general i have found that anchors are much more trouble than they seem to be worth.

in practice, if we ignore/trim leading and training whitespace as part of the re

> It may turn out that I am not of much use with xslt and java
> improvements. -Andreas

so far your feedback and alternatives have been very helpful!  i can take care of XSLT and Java, as the above links show they are just one version of a much broader story.

please keep going as you see fit, this will take several of us to sort out.  the problem is slowly but steadily yielding.  the value to ensure correct X3D content is broadly applicable.

meanwhile added some more Java unit tests tonight for SFFloat SFDouble and SFTime.  Caught the unnecessary restriction on negative SFTime values, now fixed.

> On Mon, Jul 23, 2018 at 2:05 AM Don Brutzman <brutzman at nps.edu> wrote:
>>
>> On 7/22/2018 11:40 AM, Don Brutzman wrote:
>>> [...]
>>> Will shift focus to junit5 testing at this point to facilitate experimentation.  We can put our test cases both on regex101.com and also in test suite, both for coverage and for independent checks.
>>
>> OK X3DJSAIL finally has a test harness in place.  The invocation for new ant task <junitlauncher> still fails, but direct invocation of the class works.
>>
>> X3D Java Scene Access Interface Library (X3DJSAIL) provides a set of unit tests in org.web3d.x3d.tests.FieldObjectTests to check these regexes against default and alternative values.  Initial tests in place for SFBool, SFInt32, SFFloat.
>>
>> Source code online at
>> https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/org/web3d/x3d/tests/FieldObjectTests.java
>>
>> Ant stylesheets/java/build.xml target in X3DJSAIL project:
>>
>> <target name="test.junit5.directly" description="Test X3DJSAIL using JUnit5, direct invocation of code" depends="antVersionCheck">
>>           <java classname="org.web3d.x3d.tests.FieldObjectTests" fork="${fork}">
>>                <classpath>
>>                   <pathelement location="${java.classes.dir}" />
>>                   <pathelement location="${env.ANT_HOME}/lib/junit-platform-commons.jar" />
>>                   <pathelement location="${env.ANT_HOME}/lib/junit-platform-engine.jar" />
>>                   <pathelement location="${env.ANT_HOME}/lib/junit-platform-launcher.jar" />
>>                   <pathelement location="${env.ANT_HOME}/lib/opentest4j-1.1.0.jar" />
>>                   <pathelement location="${env.ANT_HOME}/lib/jupiter/junit-jupiter-api.jar" />
>>                   <pathelement location="${env.ANT_HOME}/lib/jupiter/junit-jupiter-engine.jar" />
>>                </classpath>
>>           </java>
>> </target>
>>
>> test output:
>> =====================
>> test.junit5.directly:
>> FieldObjectTests start...
>> FieldObjectTests.fieldObjectInitializationsTest() start...
>> Preliminary tests...
>> SFBoolObjectTests...
>> SFInt32ObjectTests...
>> SFFloatObjectTests...
>> FieldObjectTests.fieldObjectInitializationsTest() complete
>> FieldObjectTests complete
>> =====================
>>
>> Example excerpt shows how tests are typically structured.  Am striving to show support for detecting both correct and incorrect values.
>>
>>       @Test
>>       @DisplayName("Test SFFloatObject single-field single-precision floating-point number")
>>       void SFFloatObjectTests()
>>          {
>>           System.out.println ("SFFloatObjectTests...");
>>           SFFloatObject testSFFloatObject = new SFFloatObject(); // static initializer is tested, might throw exception
>>           assertTrue  (testSFFloatObject.matches(),         "testSFFloatObject.matches() tests that object initialization correctly matches regex");
>>           assertEquals(0.0f, SFFloatObject.DEFAULT_VALUE,   "test correct default value for this field object");
>>           assertTrue  (SFFloatObject.matches(SFFloatObject.DEFAULT_VALUE_STRING),
>>                                                             "SFFloatObject.matches(SFFloatObject.DEFAULT_VALUE_STRING) tests that object initialization correctly matches regex");
>>
>>           testSFFloatObject.setValue(1); // returns void because it matches (overrides) Java SAI specification interface
>>           assertEquals( 1.0f,testSFFloatObject.getValue(),  "tests that setting object value to 1 results in value of 1.0f");
>>           testSFFloatObject.setValue(1.0f); // returns void because it matches (overrides) Java SAI specification interface
>>           assertEquals( 1.0f,testSFFloatObject.getValue(),  "tests that setting object value to 1.0f results in value of 1.0f");
>>           testSFFloatObject.setValue(1.0d); // returns void because it matches (overrides) Java SAI specification interface
>>           assertEquals( 1.0f,testSFFloatObject.getValue(),  "tests that setting object value to 1.0d results in value of 1.0f");
>>           testSFFloatObject.setValue(-1); // returns void because it matches (overrides) Java SAI specification interface
>>           assertEquals(-1.0f,testSFFloatObject.getValue(),  "tests that setting object value to -1 results in value of -1.0f");
>>
>>           assertTrue  (SFFloatObject.matches( "0"),      "SFFloatObject.matches( \"0\")   tests correct string value");
>>           assertTrue  (SFFloatObject.matches( "1"),      "SFFloatObject.matches( \"1\")   tests correct string value");
>>           assertTrue  (SFFloatObject.matches("-1"),      "SFFloatObject.matches(\"-1\")   tests correct string value");
>>           assertTrue  (SFFloatObject.matches( "0.0"),    "SFFloatObject.matches( \"0.0\") tests correct string value");
>>           assertTrue  (SFFloatObject.matches( "1.0"),    "SFFloatObject.matches( \"1.0\") tests correct string value");
>>           assertTrue  (SFFloatObject.matches("-1.0"),    "SFFloatObject.matches(\"-1.0\") tests correct string value");
>>
>>           assertFalse (SFFloatObject.matches("true"),    "SFFloatObject.matches(\"true\") tests incorrect boolean string value");
>>           assertFalse (SFFloatObject.matches("blah"),    "SFFloatObject.matches(\"blah\") tests incorrect alphabetic string value");
>>           assertFalse (SFFloatObject.matches("0 1"),     "SFFloatObject.matches(\"0 1\")  tests incorrect array as string value");
>>           assertFalse (SFFloatObject.matches("0.0 1.0"), "SFFloatObject.matches(\"0.0 1.0\") tests incorrect array as string value");
>>       }
>>
>> 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
> 
> 
> 


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




More information about the x3d-public mailing list