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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] how to best integrate XML in a programming language

[ Lists Home | Date Index | Thread Index ]

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.
>
>In Wheat, we use templating based approach:  If a program wants to 
>generate an XML document of type X, then the programmer creates an actual 
>example XML document of type X.  Next the template is marked up with 
>elements and attributes from a the template namespace.  These define which 
>portions of the document are manipulatable by the running program.  The 
>program then calls for the expansion of the template, directing the 
>expansion of the marked up sections.  The template expander can then 
>ensure that a well-formed XML document results.

Gee, that sounds like my description of XSLT when I teach it.

>We don't have literals that are XML.  In Wheat there is a close 
>isomorphism between a Wheat object and its XML representation.  So, 
>instead, Wheat has object literals.  These are always "well formed".
>The object can be turned into XML on demand.

Why not start off as XML in another namespace?

>         <html>
>           <head>
>             <title><?script $title ?></title>
>           </head>
>           <body>
>             <?script for ($i = 1; $i < 10; $i++) { ?>
>               <p><?script $i ?></p>
>             <?script } ?>
>           </body>
>         </html>

Processing instructions are out-of-line constructs, without any 
structure.  Where in the above is there any support *in the syntax* for 
ensuring the end of loop correctly wraps a well-formed portion of the tree?

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.

Also, I believe any out-of-line system treats XML as a syntax stream, not 
as a data model of nodes.  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.  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.

>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 ... and the designers did a 
wonderful job of taking advantage of the data model of XML to ensure the 
data model of XML can be used without jeopardizing the resulting data 
model.  XSLT leaves the worries about the syntax and the well-formedness of 
the result to the processor, not burdening the stylesheet writer, so the 
stylesheet writer does not have to think about the syntax or 
well-formedness of the result and can focus on their information.

................... Ken


--
Public courses: upcoming world tour of hands-on XSL training events
Each week:    Monday-Wednesday: XSLT/XPath; Thursday-Friday: XSL-FO
Washington, DC: 2004-03-15            San Francisco, CA: 2004-03-22
Hong Kong: 2004-05-17    Germany: 2004-05-24    England: 2004-06-07
World-wide on-site corporate, government & user group XML training!

G. Ken Holman                  mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.           http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0     +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness   http://www.CraneSoftwrights.com/x/bc





 

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

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