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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Improved template syntax and connection with XForms (WAS: InnerXml is li

[ Lists Home | Date Index | Thread Index ]

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




 

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

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