[X3D-Public] [X3D] X3D WG Agenda - 22 May 2013; SAI changes outlined

Wed May 22 09:48:29 PDT 2013

Summary:  we performed a design review to define potential changes to 
the family of X3D Scene Access Interface (SAI) specification to 
accommodate handling the UNIT statement.

Participants:  Len Daly, Dick Puck, Don Brutzman.

UNIT definitions can be found in the X3D Abstract Specification:
7.2.5.5 UNIT statement
http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/core.html#UNITStatement

Our design guideline for needed additions:  scene UNITs are defined in a 
similar manner as COMPONENTs, and so should likely get similar treatment 
in the API.

Contributions will be needed to show the proper additions of UNIT 
support to SAI implementations.

Details follow.  (Additional meeting minutes will be sent separately by 
Len.)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - -

On 5/21/2013 4:58 PM, Leonard Daly wrote:
> Our next meeting is on Wednesday, 22 May 2013 at 8:00 AM PDT (GMT-0700).
> [...]
>
> 6. 19777-1 Text (All)
> 6.1. Start with V3.3 19775-2 to identify changed sections

19775-2 ISO/IEC 19775-2:2010/PDAM1 Am1:201x V3.3 X3D Scene access 
interface (Change Document) PDAM Jan 2012
http://www.web3d.org/files/specifications/19775-2/V3.3/Part02/X3D_SAI.html

and

19775-2 ISO/IEC 19775-2.2:2010 	V3.2 	X3D Scene access interface Edition 
2 IS Jan 2011
http://www.web3d.org/files/specifications/19775-2/V3.2/Part02/X3D_SAI.html

> 6.2. Add changes from Disposition of Comments document
> 6.3. Summary of changes:
> 6.3.1. Data type: SAIUnitDeclaration

http://www.web3d.org/files/specifications/19775-2/V3.3/Part02/dataRef.html
5.2 Data type definitions
==================================
Insert alphabetically the following new data type definition and 
renumber the subsequent items.
"5.2.35 SAIUnitDeclaration

SAIUnitDeclaration defines all the information about units and its 
declaration. It is used to represent the unit information declared in 
for a file, either explicitly or by default."
==================================

The above change gets appled to the prior version of SAI:

5 Data type reference
http://www.web3d.org/files/specifications/19775-2/V3.2/Part02/dataRef.html

5.2 Data type definitions
http://www.web3d.org/files/specifications/19775-2/V3.2/Part02/dataRef.html#DataTypeDefinitions

Now the additional documents where this change also applies are the two 
language bindings for ECMAScript and Java.
Suggest changes follow, which will need implementation prior to acceptance.

19777-1 ISO/IEC 19777-1:2006 V3.0 X3D language bindings: ECMAScript IS 
May 2006
http://www.web3d.org/files/specifications/19777-1/V3.0/Part1/X3D_ECMAScript.html

5 Tables
http://www.web3d.org/files/specifications/19777-1/V3.0/Part1/tables.html
5.2 Mappings of abstract names to ECMAScript binding names
5.2.4 Browser services
Table 5.6 — Browser services listed alphabetically by abstract name

For example, note presence of:
getSupportedComponents 	Browser property ComponentInfo supportedComponents
getComponent 	array access of ComponentInfo element

therefore add:
getSupportedUnits 	Browser property UnitInfo supportedUnits
getUnit 		array access of UnitInfo element

We will continue with this editorial review and put out a more thorough 
document that attempts to capture all changes.

Performing a similar spot check on the Java bindings:
19777-2 ISO/IEC 19777-2:2006 V3.0 X3D language bindings: Java 	IS May 2006
http://www.web3d.org/files/specifications/19777-2/V3.0/Part2/X3D_Java.html
4 Tables
4.2.4 Browser services
Table 4.6 — Browser services listed alphabetically by abstract name

Note presence of:
getSupportedComponents 	ComponentInfo[] getSupportedComponent()
getComponent 	ComponentInfo getComponent(java.lang.String, int)

therefore add:
getSupportedUnits UnitInfo [] getSupportedUnit()
getUnit 	  UnitInfo getUnit(java.lang.String, int)

So it looks like the design pattern holds just fine, as was expected 
during the original SAI review that was performed when UNIT statements 
were added in X3D v3.3.

Dick noted a serious potential deficiency:  it is not clear that all of 
the services required by the abstract SAI 19775-2 are equivalently 
defined in the corresponding 19777-1 Ecmacscript and 19777-2 Java 
language bindings.  In addition to services, the data definitions should 
be similarly reviewed for completeness.

Dick is submitting some other spec comments on peripheral deficiencies 
so that nothing is overlooked in the final review.

> 6.3.2. 4 services (getUnits, getUnitCategory, getUnitConversion, getUnitName)

will follow similar review/edit pattern as defined above.

> 7. JavaScript changes to handle overloading of variables and function names

(apparently should be agenda outline item 6.3.3)

http://www.web3d.org/membership/login/mantis/view.php?id=525

Suggested specification prose can be found on entry 1038
http://www.web3d.org/membership/login/mantis/view.php?id=525#c1038
[Likely specification additions to prevent pathological cases:]

==================================
It is an error to simultaneously define fields that result in overloaded 
(i.e. duplicated) method names.

EXAMPLE The following is erroneous:
Script {
     inputOnly SFBool set_overloadedField
     inputOutput SFBool overloadedField false
}

Similarly, it is also an error to simultaneously define a method that 
directly matches and overloads an inputOutput field name. To do so 
overloads definitions for the method object and the field object.

EXAMPLE The following is erroneous, the method should instead be named 
set_overloadedField2:
Script {
     inputOutput SFBool overloadedField2 false
     url "ecmascript: function overloadedField2 (value, timestamp) { ... }"
}
==================================

Go-forward plan:
a.  Don perform next round of editing on a hardcopy and then send fully 
marked up .pdf with suggested changes to group.
b.  Review changes on teleconference, add spec-change entries into Mantis.
c.  Get 2 implementations (each) for Javascript and Java.
d.  Web3D Consortium members review, improve, approve.
e.  Submit draft specification change as New Work Item Proposal (NWIP) 
to ISO.

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