OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   dynamic elements

[ Lists Home | Date Index | Thread Index ]
  • To: XML-Dev <xml-dev@lists.xml.org>
  • Subject: dynamic elements
  • From: James William Pye <flaw@rhid.com>
  • Date: Tue, 22 Feb 2005 06:33:51 -0700
  • Organization: rhid development


Okay, I got an XSLT implementation of part of the idea.

I imagine the most interesting part of this for most people would be
Elementals[macros]. If so, take a look at the end of this letter for a
quick example of use.

I don't think I can actually do a seamless implementation of the full
idea in XSLT, as it would require the ability to do includes at runtime
and either calls to functions in arbitrary namespaces or mode selection
in arbitrary namespaces. Although, it would be nice if I could, as all
it would require would be a simple <xsl:include
href="http://rhid.org/xml/de/xslt/1.0"/>, and elements within namespaces
that are said to specify DEs would be auto-magically expanded as one
would like to expect(if the namespace specifies the location of a "DE
protocol implementing" XSLT).
[If I'm missing something, please inform me, as I would be very happy to
get a full, seamless implementation in XSLT, maybe 2.0 has some features
that would help resolve this problem?]

Considering that this whole mess sits on top of namespaces, I don't
think it desirable to say that they should be usable within namespace
declarations. IMO, an xmlns IRI scheme should be employed to allow
referencing namespace IRIs of already bound prefixes. I imagine that it
should be terminable with at least a '#' or a '/' so that extensions to
an already bound prefix could be used without having to respecify the
entire IRI(thinking of RDF folk).

For attribute content, I use an S-Expression style "element content",
but I use the '$' to identify new elements. Currently, the "parser" for
this is quite fragile and only supports very simple expressions, like

To handle macro parameters, I use a separate namespace to identify the
parameter references. It currently supports simple selections based on
position, name, namespace, local-name. It, also, provides references to
the text content, the whole parameter, and the parameter element count.
<pr:text/>, <pr:parameter/>, <pr:n/>

To handle recursion, I use a special <_/> element that takes the tail of
elements from the parameters, if zero elements exist in the tail,
recursion does not occur. Parameters given directly to it will be
ignored. References to an elemental of the same name will refer to the
past definition, or nothing if there was no prior definition, rather
than signifying recursion.

[note: the XSLT's use EXSLT, and I've only tested this with libxslt]

: :::::Just run it in a bourne-type shell:::::
mkdir sandboxx && cd sandboxx
svn co http://svn.rhid.org/xml
export XML_CATALOG_FILES="$XML_CATALOG_FILES $(realpath xml/catalog)"

cat >elements <<EOX
<?xml version="1.0" encoding="utf-8"?>
<element xmlns="http://rhid.org/xml/em";
 <simple>just some text from simple</simple>

 <!-- simple order reversal, yes the <_/> is special -->

cat >xslt <<EOX
<?xml version="1.0" encoding="utf-8"?>
<transform version="1.0"
 <include href="http://rhid.org/xml/em/xslt/1.0"/>
 <template match="/">
  <apply-templates select="*" mode="em:evaluating"/>

cat >input.xml <<EOX
<?xml version="1.0" encoding="utf-8"?>
<xml xmlns="null:test" xmlns:e="elements">
 <e:paramref><an_element>this will appear in
 <in_an_attribute foo="\$(e:simple)"/>

xsltproc --load-trace --profile xslt input.xml >result
cat result
: ::::::::::::::

Any comments and/or criticisms would be appreciated.

Regards, James William Pye

This is a digitally signed message part


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS