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

Re: InnerXml is like printf (WAS: Underwhelmed)


printf variable
Joe English <jenglish@f...> wrote:

| With the right host language, it's often possible to embed a domain-
| specific language using features of host language itself.  Tcl, Haskell, 
| Scheme, Python, and Forth all have good syntactic extensibility.

Python not as much as the others, I would think.  I'd put Python and Perl
on a par here, alhough Python syntax on the whole may be "neater".  The
others, though (Tcl, Haskell, Scheme and Forth) have a fundamental notion
of "proper list" - ie. a tree! - evident in their syntax, which suits them
to the job particularly well.  (IMHO)

| When it comes to even more slightly complex output structures, though, 
| I think they're both a clear win over the explicit node-at-a-time DOM 
| interface and the InnerXml/ document.write() approach:

We all agree that printf-ing is quick and dirty. :-)

The node-at-a-time approach in DOM and its variants, I think, has a lot to
do with doctrinaire notions of correct Java style.  You have to do it that
way when mutators are "supposed" to have void return signatures.  You get
much more mileage if you set things up for method chaining, because method
invocation itself involves the largest contribution of explicit syntactic
clutter - dots, parens, commas, maybe quotes, whatnot - which ultimately
gets in the way of what you want to do, describing a tree economically.

Basically, Java doesn't have List Structure, so you have to fake it. ;-)

|     xml::element HTML {
| 	xml::element HEAD {
| 	    xml::element TITLE {
| 	    	xml::text $Title
| 	    }
| 	    xml::element LINK  type text/css  href stylesheet.css
| 	    xml::element LINK  rel next  href [nextDocument]
| 	    xml::element LINK  rel prev  href [prevDocument]
| 	}
| 	xml::element BODY {
| 	    xml::element P {
| 		xml::text "Hello world!"
| 	    }
| 	}
|     }

Syntaxes of this type fall into a general class that could be described at
a high level with a yacc spec like this

 %token  CO  CC  CS  ELEMSPEC  TEXTSPEC
 %%
 wff
  :  element
  ;
 element
  :  ELEMSPEC  CO  content  CC
  ;
 content
  :  item
  |  item  CS  content
  ;
 item
  :  element
  |  TEXTSPEC
  ;
 %%

The CS (Content Separator) is syntax sugar only; it can be removed without
losing LALR(1) (or LL(1), if things are set up right.)  There are two
states that matter, with the same issue: how to distinguish an element
specification from text content.

 state 4
        element : ELEMSPEC CO . content CC  (2)

        ELEMSPEC  shift 1
        TEXTSPEC  shift 5
        .  error

        element  goto 6
        content  goto 7
        item  goto 8

 state 10
        content : item CS . content  (4)

        ELEMSPEC  shift 1
        TEXTSPEC  shift 5
        .  error

        element  goto 6
        content  goto 11
        item  goto 8


or, without CS:

 state 8
        content : item .  (3)
        content : item . content  (4)

        ELEMSPEC  shift 1
        TEXTSPEC  shift 5
        CC  reduce 3

        element  goto 6
        content  goto 10
        item  goto 8

You get LL(1) with any prefix based approach to tell ELEMSPEC and TEXTSPEC
apart (eg. xml::element and xml::text can be viewed syntactically as just
markers).  If you put text inside quotes always, and quotes are only used
for this purpose, then that's enough too. 

So the only remaining issue is the details of ELEMSPEC.  Here again the
notion of list structure is enough: an element specification is just an
association list (where the element name can be viewed as the "value" of
an unnamed attribute, the "generic identifier"), ie a list of pairs.  Any
list of pairs, in fact!  It could be just an attribute specification list
with the element type implicit (just as all XML can be reduced to the form
<tag element-type="foo" ...>)

Not only are these syntaxes dead easy to parse, they're dead easy to write
too.  With languages like Tcl, etc, you also get the benefits of variable
interpolation and function evaluation to fill slots, but let's not get
into that.

I've always wondered why people prefer syntactic clutter instead.


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.