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

Re: how to best integrate XML in a programming language


best programming language syntax

On Friday, Feb 20, 2004, at 13:27 Europe/Berlin, G. Ken Holman wrote:

> At 2004-02-19 23:25 -0800, Mark Lentczner wrote:
>> At 2004-02-18 11:11 +0100, Burak Emir wrote:
>>> No matter whether you are more concerned about documents or data,
>>> writing XML syntax to describe XML makes life easier.
>> Not clear to me.  I don't find XSLT particularly easy or concise to 
>> write lexically.
>> ...
>> It is unrealistic that a program wants to embed a literal that is an 
>> entire XML document.  It would be more likely that a program wants to 
>> output an XML document composed of XML literals and data values from 
>> the running program.  Therefore, it is highly unlikely that the 
>> compiler could do much in the way of ensuring schema conformance.
> ...
>
> For example, where would the following be checked?
>
>             <?script for ($i = 1; $i < 10; $i++) { ?>
>               <p><?script $i ?>
>             <?script } ?>
>            </p>
>
> There would appear to be nothing preventing the above from being 
> considered incorrect until the result was created and then verified 
> for being well formed.  The well-formed requirement of XML as utilized 
> by XSLT ensures that the above could not be written, therefore, the 
> input syntax guarantees that the output syntax is well-formed, which 
> means the output need never be checked for being well-formed and it, 
> therefore, need not be cached when produced.
>
> This is why disable-output-escaping= in XSLT is so dangerous to use, 
> as the stylesheet writer can shoot themselves in the foot.  No-one 
> should advocate d-o-e= except in the most dire of situations where 
> nothing else will do.
>
> This is why *any* out-of-line system adds an entire level of 
> complexity and a burden for the stylesheet writer because they cannot 
> take advantage of well-formedness to help them ensure the 
> well-formedness of the bits of XML they are working with.
>

would those who propose typed "out-of-line" expressions agree with 
this? it depends on the out-of-line language. my impression is that the 
papers on ml-based xml processing, the document by meijer et al which 
was referenced in the initial post, and even x-query argue against that 
claim,

> Also, I believe any out-of-line system treats XML as a syntax stream, 
> not as a data model of nodes.

in that they posit a mechanism which establishes a type equivalence 
between an xml data model and a process, expressed in a syntax other 
than xml, which can be demonstrated to produce a correct data model 
and/or a well-formed encoded stream.

> ...  XSLT is *not* an angle-bracket processor, it is a node processor 
> where the nodes usually (but not always) happen to come from and go to 
> XML angle brackets.  An out-of-line system is going to require users 
> to consider syntactic issues rather than let the processors consider 
> syntactic issues.  XSLT relieves the users of this and lets people 
> focus on their information, not on their syntax.
>
> The designers of XSLT make this claim up front and don't try to hide 
> it: XSLT was not designed to preserve or manipulate the syntax of a 
> document, it was designed to be totally general purpose with the 
> information structure of a document: when the document is used by a 
> processor downstream, the choice of syntax is irrelevant as long as it 
> is correct.
>
> Now if you claim that the processor of an out-of-line system can take 
> on the burden of checking the above for well-formedness, then you've 
> given that development team a lot of responsibility (and opportunity 
> for error) that could have just been handled by an XML processor ... 
> just like XSLT does.

with the benefit, that the result "lets people focus on their 
information, not their syntax." (the statement, after all, has more 
than one sense.)

>   An XSLT processor doesn't need to check well-formedness of templates 
> because the XML processor inside the XSLT processor checks this and it 
> is available off-the-shelf.

whereby, well-formedness is a rather low bar.
>
>> It is this very problem that lead Wheat to use templates.  With 
>> templates there is clear separation: The XML document looks, feels 
>> and is authored as XML.  The code is clear, concise and compact.  The 
>> trick is making sure that the code one writes to connect the two is 
>> easy and clear.
>
> You don't describe the syntax of your system here, but I'm assuming it 
> isn't like the script above ... I don't quickly see any examples on 
> your web site of how you would do the above, but if you aren't using 
> XML syntax then I'm not sure how you can guarantee well-formedness.
>
> So, I'm not trying to measure your system or comment on it, I just 
> wanted to comment on your observations and derisions about XSLT.  It 
> seemed to me that your criticisms of XSLT were misplaced when you turn 
> around and say "templating is better" ... XSLT *is* templating ...

from the descriptions, and the reference to zope/tal, one distinction 
could be that they will be more monolithic with a recursive control 
structure, in contrast to element/component and rewrite-based.

...


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.