Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Improved template syntax and connection with XForms (WAS: InnerXml is li
Jeni Tennison mailed me offline with an excellent suggestion which I
think significantly improves on my proposal.
She pointed out that we could actually use XPath syntax directly, so
that instead of,
new Element(
"html/("+
"head/("+
"title/text(%0),"+
"link[@rel='stylesheet',@type='text/css',@uri=%1]),"+
"body/p/text(%2))",
{ "Example 3", "/ss/style.css", "Hello World" } );
we would have,
new Element(
"html["+
"head["+
"title = %0 and "+
"link[@rel = 'stylesheet' and " +
"@type = 'text/css' and " +
"@uri = %1]] and "+
"body/p = %2]",
{ "Example 3", "/ss/style.css", "Hello World" } );
which on expansion looks like this,
html[
head[
title = 'Example 3' and
link[@rel = 'stylesheet' and
@type = 'text/css' and
@uri = '/ss/style.css']] and
body/p = 'Hello World']
which, beautifully, can be used as a selector for the newly created
element.
There's a small cost in that using XPath is slightly more verbose
(" and " rather than ","), but that's more than offset, IMO, by the fact
that there are no syntactic innovations.
She also mentioned that there might be some connections with XForms. I
don't know much about XForms, so I'll quote her verbatim,
> XForms processors need (or used to need -- for some reason I can't
> access the W3C pages at the moment to check) something like this. If
> the instance data used with an XForm doesn't have a node that a
> binding element refers to then the XForms processor is supposed to
> create that node. The references to nodes take the form of XPaths, so
> basically they need to be able to do roughly what you're talking
> about, except they don't need to fill in values and they do have to
> take into account that some of the elements might already exist in the
> instance data and therefore not have to be created. Perhaps there are
> already some implementations out there.
The comment that "some of the elements might already exist" is
interesting. It suggests that some kind of merge operation would be
useful. For example, given a representation of,
<foo>
<bar a='wibble'/>
</foo>
we might want to do something like this,
Element foo = new Element("foo/bar[@a='wibble']");
Element mergee = new Element("foo[bar[@b='wobble'] and baz]");
foo.merge(mergee);
to get a representation of,
<foo>
<bar a='wibble' b='wobble'/>
<baz/>
</foo>
This isn't a million miles away from some work that one of my ex-
colleagues, Saif Khan did a while back.
It'd be interesting to see how this sort of operation would be expressed
in XOM (or JDOM, dom4j or W3C DOM for that matter).
Cheers,
Miles
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
