Literal Minded
By now you'll be thoroughly unmoved by our innovative 'Hello World' theme.
But here we're going to try one last effort to breathe life into it...
<idoc> <comment>
***************************
DPML Tutorial - App4
Copy, Literals, Xpointer
***************************
</comment> <seq> <instr> <type>copy</type> <operand>hello.xml</operand> <target>this:response</target> </instr> <instr> <type>copy</type> <operand> <p>We try to keep our promises. It's <b>already</b> marginally more interesting! </p> </operand> <target>this:response#xpointer(/html/body/p)</target> </instr> <instr> <type>copy</type> <operand> <h1>Bienvennue, Welcomme ... Ay Up</h1> </operand> <target>this:response#xpointer(/html/body/h1)</target> </instr> <instr> <type>copy</type> <operand> <i>'Ay Up', is Yorkshire for 'Greetings Old Boy'</i> </operand> <target>this:response#xpointer(/html/body/i)</target> </instr> <instr> <type>cast</type> <operand>this:response</operand> <operator> <cast> <mimetype>text/html</mimetype> </cast> </operator> <target>this:response</target> </instr> </seq> </idoc>
Try this application here
We thought we could squeeze one last example out of the theme but only now realise that it's gone
too far and for that we apologize. However...
In this application we're putting together the things we've learned in the previous sections. We have
a series of instructions each copying resources into the this:response document. What's new here is
that we are enclosing literal document fragments inline within the <operand> element.
Each instruction copies it's literal to a different xpath location in the response document, resulting in the
final transformed document you see in the final response.
More Formally
A literal is an inline document fragment with a single root node. A literal is treated just as though
it were an external resource referenced by URI. However a literal cannot be referenced it has instruction scope.
Although this application doesn't do anything interesting, literals are very useful and will occur frequently as we progress.
As you've probably already grasped, we've been using a literal all the way through these examples in the operator of the final cast instruction
- we'll reveal more on this soon.
Sequence, Sequence ... Sequence
You've probably noticed that inocuous <seq> element within which all the <instr> instructions
are placed. Well this example shows a little of why it's there. <seq> is used to identify a block
of instructions or nested blocks. Whilst at the moment this may look superfluous, we will see later that <seq> is an
essential aspect of the language and will appear in iterations and exception handling. For now it is sufficient to understand
that <seq> can wrap any block of instructions even just a single instruction. Seq's can be nested to arbitrary
depth.
Instruction Document
While we're wrapping up the loose ends lets mention <idoc> . Actually there's very little to say. An instruction
document or idoc is the generic term used in DPML to refer to an executable set of instructions. As a convention
an idoc always has <idoc> as it's root element and is always identified by URI extension ".idoc"
One optional feature is to place the idoc elements in the dpm namespace http://1060.org/dpm . Using the namespace can be
useful to distinguish literals from idoc instructions but generally using the namespace makes everything very busy so we are not using
it in this guide. Here's an example idoc which uses the namespace.
<dpm:idoc xmlns:dpm="http://1060.org/dpm"> <dpm:instr> <dpm:type>copy</dpm:type> <dpm:operand> <example>This element is not in the dpm namespace</example> </dpm:operand> <dpm:target>this:response</dpm:target> </dpm:instr> </dpm:idoc>
Note that you should never declare a default namespace for the idoc, since using a default namespace would apply to literals which is probably something
you don't generally want.
|