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: <!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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] TransformerFactory.newIns, Kevin Duffey | Thread | [xsl] XSLT: XPath: Siblings, Lee Goddard |
Re: [xsl] RE:"*NEVER* use for-each", Francis Norton | Date | Re: [xsl] RE:"*NEVER* use for-each", Eric van der Vlist |
Month |