xsl-list
[Top] [All Lists]

Re: [xsl] RE: Are there things missing in XSLT which force people to use, say, Java to process XML?

2010-10-31 03:05:40
See inline for some additions to my original questions.

My personal rating with respect to XSLT's qualitiy for programming in
the large is that XSLT
has sufficient features for permitting the combination of modules
without running into conflicts,
that XSLT does not address the issues of type definition and
conformance of processing
intruction to (schema) types sufficiently enough for my liking. Apart
from the built-in
functions, there is no "standard library" (not even a simple
formatting utility such as printf).
Section 1.1 of the XSLT of the W3C recommendation answers the question
"What is XSLT?"
Nowhere does it claim that XSLT is a "general purpose" programming
language. If it isn't,
then it should not be recommended for *unqualified* "programming in
the large"; it is,
certainly, extremely well qualified for large and complex
transformations of XML data.

It would be interesting to learn about some industry data, such as the number of
lines of code resulting from and/or person years spent on a single
XSLT project.


On 30 October 2010 22:43, G. Ken Holman 
<gkholman(_at_)cranesoftwrights(_dot_)com> wrote:

At 2010-10-30 19:59 +0200, Wolfgang Laun wrote:

Is there any way that I can write a stylesheet module, to be imported
by others, so that I expose the functions and templates I consider
being part of the "published interface" but forbid the use of certain
local templates or functions (which would permit me to change them
without breaking other code)?

Thus, we used a "private" namespace for the library's internal modes, keys, 
variables and template names, so that there would be no inadvertent overrides 
by shell stylesheets.  But there were aspects of the library that the users 
could control, and so we used a second "public" namespace for the library's 
exposed global named constructs.  We only published the URI for the public 
namespace (or perhaps we documented the private namespace somewhere but 
indicated it was off limits and users were only to use the public namespace).

I understand this to mean that you have to rely on "common decency" on
the client's side and that there is no stringent way. In all fairness
(to XSLT) I should say that there are other renowned languages where
this can't be enforced, too. The namespace distinction is "heavy" as
you have to use it in the modules you write; a modifer attribute might
be simpler to use, and it provides absolute control.



If there is a module with templates matching some specific XML
hierarchy (<x><y z="">...</</), is there a straightforward way of
reusing that for a structurally identical XML hierarchy?

Not sure what you mean by that.  If it is identical, then it just gets used, 
not reused.  Do you mean used with different names but the same tree shape?

Yes, sorry - I should have added: "...hierarchy, e.g., for <a><b c="">...</</.)


W3C has defined XML, XML Schema and XSLT, but there is no way (I know)
of aligning a data definition (e.g., a ComplexType) with an XSLT
module defining operations on such an entity. Or is there?

In XSLT 2.0 you can match on type regardless of name using:

 <xsl:template match="element(*,my:address)

Matching on a type is not the same as checking a type. If you write
   <xsl:template match="element(address,my:address)
and if there is an address but with any other type than my:address,
nothing happens.


XSLT is (understandably) focussed on the data types and structures
found in XML and XML Schema. There is no way (again: I know of) for
defining really new data types in a way comparable to, say, Haskell.
Or is there?

Sorry, Wolfgang, I don't know Haskell to compare.  As you say, the *only* 
data types are found from W3C Schema or user-defined schema types.

Michael has answered this one.

Regards
Wolfgang

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>