[x3d-public] X3D Object Model and X3D XML Schema attributeGroup definitions for DEF, USE, class
Don Brutzman
brutzman at nps.edu
Sat Oct 29 23:22:04 PDT 2016
Thanks for getting this closer.
Am hesitant to overload InterfaceDefinition in the X3D Object Model functionality in that tagset, it has a pretty clear collection role already. That XML approach is a bit different than the XML-schema-style excerpt below.
Of note is that DEF/USE/class are already unambigously defined in the XML schema, allowing .x3d validation, so I think the specific challenge is to map that to X3D Object Model .xml version.
Also of note:
a. we have set things up so that each ConcreteNode definition is complete; abstract relationships in Schema get fully elaborated. So ref attributes should likely be avoided when possible.
b. The X3D statements have used the same <field> nomenclature for attributes. Example:
<Statement name="X3D">
<InterfaceDefinition specificationUrl="http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#Header"
appinfo="X3D is the root node for an Extensible 3D (X3D) Graphics model.">
<componentInfo name="Core" level="1"/>
<field type="SFNode" accessType="inputOutput" name="head" default="NULL"
acceptableNodeTypes="head"/>
<field type="SFString" accessType="inputOutput" name="profile" default="Immersive"
use="required"
baseType="profileNames">
<enumeration value="Core"/>
<enumeration value="Interchange"/>
<enumeration value="CADInterchange"/>
<enumeration value="Interactive"/>
<enumeration value="Immersive"/>
<enumeration value="MedicalInterchange"/>
<enumeration value="MPEG4Interactive"/>
<enumeration value="Full"/>
</field>
<field type="SFNode" accessType="inputOutput" name="Scene" default="NULL"
acceptableNodeTypes="Scene"/>
<field type="SFString" accessType="inputOutput" name="version" default="3.3"
use="required"
baseType="x3dVersion">
<enumeration value="3.0"/>
<enumeration value="3.1"/>
<enumeration value="3.2"/>
<enumeration value="3.3"/>
</field>
<ContentModel>
<StatementContentModel name="head" minOccurs="0"/>
<StatementContentModel name="Scene"/>
</ContentModel>
</InterfaceDefinition>
</Statement>
c. i had avoided assigning accessType to a non-element attribute, but that might be too file-centric. If we think in object terms, for example HTML5/DOM (or even JSON), then DEF/USE/class values need to be settable. Practically speaking, listenable as well so that changes can be propagated at run time - e.g. DOM "bubbling" listeners etc. the preceding example for <Statement name="X3D"> presents a useful design i will attempt to pattern after.
d. likely still a good idea to get globally consistent about types xs:ID xs:IDREF xs:NMTOKEN and xs:NMTOKENS. am holding back on this one until we are ready to apply it throughout.
e. thus next refinement would be
<field type="SFString" accessType="inputOutput" name="DEF" default="" inheritedFrom="X3DNode"/>
<field type="SFString" accessType="inputOutput" name="USE" default="" inheritedFrom="X3DNode"/>
<field type="SFString" accessType="inputOutput" name="class" default="" inheritedFrom="X3DNode"/>
accomplished by adding rules that apply <xs:attributeGroup> entries in X3D XML schema within the BuildObjectModelXmlFile.xslt stylesheet.
f. From an object-model perspective, bstract type X3DNodeMixedContent is the same as X3DNode, simply providing a schema-specific approach to allow plain-text content.
Made some slight modifications to replace in object model creation to replace X3DNodeMixedContent with X3DNode. Turns out there was one case like that already, so this improves consistency.
have applied XSLT rules to carry out this pattern.
g.evaluation update attached, please let me know what you think. seems OK... once we are re-converged will check in converter additions and deploy.
... correction. it is getting a bit long, and is also involved to test. it is better to check the diffs and easier to modify the corrected version.
https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/BuildObjectModelXmlFile.xslt
https://sourceforge.net/p/x3d/code/23763/
modified X3D object model attached. test results with X3D Java SAI Library in next message...
On 10/26/2016 4:32 PM, Roy Walmsley wrote:
> Hi Don,
>
> Yes, we have missed adding DEF/USE and class to the object model. With reference to your suggested methods of addition I do not favour a) adding them as a field. They are not fields, and I wouldn't like to raise confusion in the minds of those who might be struggling to understand everything clearly. In fact, I would probably go for c) something else, so as to identify them in an alternate manner. I have two half suggestions.
>
> Consider the Object Model schema. Here is an extract that covers the InterfaceDefinition element within a ConcreteNode element.
>
> <xs:element name="InterfaceDefinition">
> <xs:annotation>
> <xs:documentation>This element contains an interface definition for an abstract object, abstract node, or concrete node</xs:documentation>
> </xs:annotation>
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="componentInfo" minOccurs="0"/>
> <xs:element ref="Inheritance" minOccurs="0"/>
> <xs:element ref="AdditionalInheritance" minOccurs="0" maxOccurs="unbounded"/>
> <xs:element ref="field" minOccurs="0" maxOccurs="unbounded"/>
> <xs:element ref="containerField" minOccurs="0"/>
> <xs:element ref="ContentModel" minOccurs="0"/>
> </xs:sequence>
> <xs:attribute name="specificationSection" type="xs:string" default=""/>
> <xs:attribute name="specificationUrl" type="xs:string" default=""/>
> <xs:attribute name="appinfo" type="xs:string" default=""/>
> </xs:complexType>
> </xs:element>
>
> Notice that we have a separate element for containerField. So maybe we add them as separate entities, similarly. Or another approach might be to add them as attributes to the ConcreteNode element.
>
> <xs:element name="ConcreteNode">
> <xs:annotation>
> <xs:documentation>This element contains the definition for a single X3D concrete node type</xs:documentation>
> </xs:annotation>
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="InterfaceDefinition"/>
> </xs:sequence>
> <xs:attribute name="name" type="xs:token" default=""/>
> </xs:complexType>
> </xs:element>
>
> We could add additional attributes, one each for the three items.
>
> What do you think?
>
> Roy
>
> -----Original Message-----
> From: Don Brutzman [mailto:brutzman at nps.edu]
> Sent: 26 October 2016 21:00
> To: Roy Walmsley <roy.walmsley at ntlworld.com>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: X3D Object Model and X3D XML Schema attributeGroup definitions for DEF, USE, class
>
> While using the X3D Object Model to autogenerate Java SAI Library, noticed some interesting omissions.
>
> 1. First, XML Schema has the following attributeGroup definitions for DEF, USE, class
>
> http://www.web3d.org/specifications/x3d-3.3.xsd
> <!--======================================================================-->
> <!--Attribute groups-->
> <!--DEF and USE are node-naming attributes common to all instantiable nodes. This attributeGroup is defined for all top-level node types in the node interface hierarchy.-->
> <xs:attributeGroup name="DEF_USE">
> <xs:annotation>
> <xs:documentation source="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics"/>
> </xs:annotation>
> <xs:attribute name="DEF" type="xs:ID">
> <xs:annotation>
> <xs:documentation source="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics"/>
> </xs:annotation>
> </xs:attribute>
> <xs:attribute name="USE" type="xs:IDREF">
> <xs:annotation>
> <xs:documentation source="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics"/>
> </xs:annotation>
> </xs:attribute>
> </xs:attributeGroup>
> <xs:attributeGroup name="globalAttributes">
> <xs:attribute name="class" type="xs:NMTOKENS">
> <xs:annotation>
> <xs:appinfo>
> The class attribute is a space-separated list of classes, reserved for use by XML stylesheets.
> </xs:appinfo>
> <xs:documentation source="http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#ClassAttributeSyntax"/>
> </xs:annotation>
> </xs:attribute>
> </xs:attributeGroup>
> <!--======================================================================-->
>
>
> 2. Second, these groups are referenced in X3DNode, X3DNodeMixedContent, ProtoInstance, MetadataSet, X3DProgrammableShaderObject, X3DScriptNode, ComposedShader.
>
> - X3DNode, X3DNodeMixedContent are expected, they are topmost (mixed content refers to contained CDATA plain-text scripts).
> - ProtoInstance is a special wild-card node that requires special handling in the node hierarchy.
> - MetadataSet had some complications that we sorted out in this fashion, I believe 2 Mantis issues pertain to these.
> http://www.web3d.org/member-only/mantis/view.php?id=848
> http://www.web3d.org/member-only/mantis/view.php?id=834
> - I think X3DProgrammableShaderObject, X3DScriptNode, ComposedShader relate to mixed content and special schema arrangements, for example:
> <!-- ComposedShader does not derive from X3DNode because of the need to have field children come first, before IS and ChildContentModelCore. -->
>
> In short, all of these functionally derive from X3DNode, and any variations in the Schema are solely due to schema strictness (usually relating to avoidance of nondeterministic content models among the various cross-referencing inheritances).
>
> Supporting reference for object model is abstract spec, 4.4.2.3 Interface hierarchy http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#InterfaceHierarchy
>
> Related reference is X3D XML Schema Documentation http://www.web3d.org/specifications/X3dSchemaDocumentation3.3/x3d-3.3.html
>
> Repeating key point: all three of these attributes functionally derive from X3DNode.
>
>
> 3. In any case, these common attributes need to be listed in the X3D object model.
>
> a. Am thinking that most consistent approach might simply be adding them to all nodes, e.g.
>
> <field type="SFString" accessType="" name="DEF" default="" inheritedFrom="X3DNode"/>
> <field type="SFString" accessType="" name="USE" default="" inheritedFrom="X3DNode"/>
> <field type="SFString" accessType="" name="class" default="" inheritedFrom="X3DNode"/>
>
> b. Alternatively we might use type="NMTOKEN" for DEF/USE, and similarly use that definition elsewhere (e.g. name="name" attributes).
>
> c. Something else?
>
> All feedback welcome. Thanks for considering this representation issue.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: X3DObjectModel-3.3.xml
Type: text/xml
Size: 768919 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161029/861f9287/attachment-0001.xml>
More information about the x3d-public
mailing list