[
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
|
