This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
X3D issues for XSLT, from XSL group meeting 27 FEB 2001
- To: XSL list <xsl-list at lists dot mulberrytech dot com>
- Subject: [xsl] X3D issues for XSLT, from XSL group meeting 27 FEB 2001
- From: Don Brutzman <brutzman at nps dot navy dot mil>
- Date: Tue, 27 Feb 2001 14:04:28 -0500
- CC: Sharon Adler <sca at us dot ibm dot com>, X3D Contributors <x3d-contributors at web3D dot org>
- Organization: Naval Postgraduate School
- Reply-To: xsl-list at lists dot mulberrytech dot com
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:
<!DOCTYPE X3D PUBLIC
"http://www.web3D.org/TaskGroups/x3d/translation/x3d-compact.dtd"
"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
http://www.w3.org/TR/2001/PR-xhtml-modularization-20010222
http://www.w3.org/TR/2000/REC-xhtml-basic-20001219
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.
References:
http://www.web3d.org/x3d.html
http://www.web3d.org/TaskGroups/x3d/translation/x3d-compact.dtd
http://www.web3d.org/TaskGroups/x3d/translation/X3dToVrml97.xsl
http://www.web3d.org/TaskGroups/x3d/translation/X3dToHtml.xsl
[watch out for line splits of URLs]
Extensive content examples transformed using these stylesheets:
http://www.web3d.org/TaskGroups/x3d/translation/examples/Vrml2.0Sourcebook/toc.html
Parameter-entity X3D extension example.
[you may need to inspect source XML to reveal constructs]
http://www.web3d.org/TaskGroups/x3d/translation/examples/development/SpinGroupParameterEntityDeclaration.xml
http://www.web3d.org/TaskGroups/x3d/translation/examples/development/SpinGroupParameterEntityDeclaration.wrl
http://www.web3d.org/TaskGroups/x3d/translation/examples/development/SpinGroupParameterEntityDeclaration.html
Internal subset declaration:
http://www.web3d.org/TaskGroups/x3d/translation/examples/development/SpinGroupInternalSubsetDeclaration.xml
http://www.web3d.org/TaskGroups/x3d/translation/examples/development/SpinGroupInternalSubsetDeclaration.wrl
http://www.web3d.org/TaskGroups/x3d/translation/examples/development/SpinGroupInternalSubsetDeclaration.html
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
ProtoTagDtdDeclarationExamples.xml
-->
<!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:
http://www.web3d.org/TaskGroups/x3d/translation/X3dSchemaDraft.xml
http://www.web3d.org/TaskGroups/x3d/sai/SceneAuthoringInterface.html
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