[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

dynamic elements

• To: XML-Dev <xml-dev@l...>
• Subject: dynamic elements
• From: James William Pye <flaw@r...>
• Date: Tue, 22 Feb 2005 06:33:51 -0700
• Organization: rhid development

Greets,

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
'$(nsp:ln)'.

[Elementals/macros]
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"
xmlns:pr="http://rhid.org/xml/pr">
 <simple>just some text from simple</simple>
 <paramref><pr:n1/></paramref>

 <!-- simple order reversal, yes the <_/> is special -->
 <tail_recursion><_/><pr:head/></tail_recursion>
</element>
EOX

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

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

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

• Prev by Date: RE: schema keyref to other schema.
• Next by Date: <offtopic> Jobs
• Previous by thread: schema keyref to other schema.
• Next by thread: <offtopic> Jobs
• Index(es):
  • Date
  • Thread