[xsl] X3D issues for XSLT, from XSL group meeting 27 FEB 2001

Subject: [xsl] X3D issues for XSLT, from XSL group meeting 27 FEB 2001
From: Don Brutzman <brutzman@xxxxxxxxxxxx>
Date: Tue, 27 Feb 2001 14:04:28 -0500
Extensible Stylesheet Language (XSL) working group meeting (Tuesday morning).  
Two topics discussed pertaining to X3D:
== XSLT infoset issues for X3D
== experience using XSLT to generate APIs from schema


I described progress and challenges that X3D is having with XSLT. 
Details, advice from participants and discussion comments follow.

Extensible 3D (X3D) is the XML encoding of the VRML 200x specification.
We have a DTD, schema and numerous example scenes.  XSLT has been 
instrumental in much of our progress to date.   

A major X3D design goal is componentization, where components can match 
new nodes and profiles are groups of nodes.  We currently have the 
following profiles:
- Core, which is a small-footprint strict subset of BaseLine
- BaseLine, which is slightly larger than VRML 97 ISO spec
- Four disjoint new profiles (GeoVRML, HumanoidAnimation, NURBS, DIS)

We further wish to show how new components (nodes) and new profiles
(node collections) can be freely added in the future, as desired by 
authors/companies, without needing to incorporate such nodes/profiles
in the official specification.  Author-level control in documents
is an important capability in order to ensure that downloaded
plugin components (triggered by document content) are as 
lightweight as possible.  Author-level control is also needed for 
document validation for new-tag content (of course).

Currently our extension mechanism for authors is to employ
DTD fragments in the DOCTYPE internal subset.  These enable/disable
profiles in the master DTD.  Example:

 "file://localhost/www.web3D.org/TaskGroups/x3d/translation/x3d-compact.dtd" [
 <!ENTITY % BaseLineProfile    "INCLUDE">
 <!ENTITY % CoreProfile        "IGNORE">
 <!ENTITY % DisJavaVrmlProfile "INCLUDE">
 <!ENTITY % GeoVrmlProfile     "INCLUDE">
 <!ENTITY % HAnimProfile       "INCLUDE">
 <!ENTITY % NurbsProfile       "INCLUDE">

Authors are also allowed to define new nodes and attributes.  
(See internal subset declaration example/excerpt below.)

Unfortunately, XSLT infoset constraints prevent looking at any of these 
DTD fragments in a document's internal subset.  As a result, a
stylesheet cannot determine what new elements and parameter entities 
are declared.

The XSL group attendees offered the following advice:
- look at Oracle X-SQL servlets used multiple DTDs
- multiple processing instructions (PIs), corresponding to profiles
  or perhaps even each newly defined node/attribute 
- fixed attribute values corresponding to DTDs, inspectable in the
  document via XSLT?
- Future XSLT ability to determine document subset definitions is
  "extremely unlikely," for a variety of reasons, including that 
  many XML parsers do not retain such information.
- look at Modularization, Basic XHTML approaches

Issues that still appear problematic for X3D components and XSLT:
- DTD fragments in document's internal subset are not transformable
  into prose, pretty-print HTML or indeed anything, preventing 
  effective presentation/dissemination of learning examples
- combinatorics of multiple DTDs for multiple profiles
- requirement to enable future componentization means that
  extension examples must be reasonably simple & repeatable.
  Duplicating node/attribute definitions with PIs or other
  constructs is probably to error-prone/heavyweight for authors.

Next steps and likely outcomes for X3D:
- examine suggestions by XSL group
- write up limitations in current X3D extensibility via DTD fragments
  (this message thread is a good summary of details)
- examine schema + namespace approaches as more robust alternative
- develop compatible DTD/schema approach; implement and evaluate
- may need to avoid author definition of new XML X3D tags completely,
  relying solely on VRML/X3D PROTO/ProtoDeclaration mechanisms.


[watch out for line splits of URLs]
Extensive content examples transformed using these stylesheets:

Parameter-entity X3D extension example. 
[you may need to inspect source XML to reveal constructs]

Internal subset declaration:
which includes definitions like this:

<!-- SpinGroupInternalSubsetDeclaration.xml:  an example scene demonstrating
     how to extend the X3D DTD to accept and validate a new node.

     The extension-node type declaration goes here in the internal subset.
     It will override the null-string declaration in the external X3D DTD.

<!ENTITY % GroupingNodeExtensions "SpinGroupTag | " >

<!-- Now define the node so that content and attribute types are valid.
     This only works when child content is specified explicitly.
     The author must carefully match the DTD patterns without error!
     Complete examples for all node types are found in 

<!ELEMENT SpinGroupTag (fieldValue*, children?) >
<!ATTLIST SpinGroupTag 
	translation      NMTOKENS "0 0 0"
	rotation         NMTOKENS "0 0 1 0"
	center           NMTOKENS "0 0 0"
	cycleInterval    NMTOKEN  "1"
	nodeTypeHint     NMTOKEN  #FIXED   "Group"
	DEF              ID       #IMPLIED 
	USE              IDREF    #IMPLIED>


Further discussion looked at issues arising from existence of multiple
APIs and language bindings, for XSLT and other XML languages.
(For a good example of this, see MathMl which has a lot of 
perhaps-unnecessary redundancy in five similar, functionally 
matching appendices.)

We have been using Schema and XSLT extensively for development of the 
X3D graphics spec.  Specifically we are using XSLT for

- stylesheet translation of documents, XML->VRML encoding and vice versa
- transformation of X3D schema for rapid autogeneration of a matching 
  high-performance API, the Scene Authoring Interface (SAI) in Java
- enabling few & precise matchup points between SAI and DOM interfaces
- this approach using stylesheets will also let us autogenerate
  spec API annexes for IDL, EcmaScript, Java et al. as desired
- identifying nodes implementing multiple interfaces (still clumsy)
- profiling plans for componentization, dependence on namespaces

I believe that W3C ought to work towards a similar approach in W3C
recommendations, so that API annexes might be autogenerated from schema 
and become 100.0% interlocking and consistent, rather than hand edited.

Further references:

If my other bag catches up, I'll have some CDs with these materials 
available in a few days.  The 2 X3D Software Development Kit (SDK) CDs 
are online at http://sdk.web3d.org


Thanks for offered comments and advice.

all the best, Don
Don Brutzman  Naval Postgraduate School, Code UW/Br Root 200  work 831.656.2149
              Monterey California 93943-5000 USA              fax  831.656.3679
Virtual worlds/underwater robots/Internet     http://web.nps.navy.mil/~brutzman

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread