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

Re: RE: Are there things missing in XSLT which force

Subject: Re: RE: Are there things missing in XSLT which force people to use, say, Java to process XML?
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 30 Oct 2010 16:43:32 -0400
Re:  RE: Are there things missing in XSLT which force
At 2010-10-30 19:59 +0200, Wolfgang Laun wrote:
Some questions, out of ignorance, but driven by curiosity. I have
addressed a few point that (I think) are required for programming in
the large. ("Large" has no upper bound, has it, Ken ;-) )

(true!)


On 29 October 2010 22:43, G. Ken Holman <gkholman@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> XSLT absolutely was designed for "programming in the large",

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)?

I had to do this on one project where the stylesheet library was being sent out to remote locations for customized deployment without the development team being present to help. Thus, we didn't know what "shell" stylesheets were going to be written to use the library.


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).

The project was for the publishing of US Intelligence documents: although the library presented the document in a default presentation, each group of analysts around the world (Strategic Command, Central Command, US Forces South Korea, Coast Guard, etc.) could write their own shell stylesheets to import the library. Using the two namespaces, private and public, there were no problems of the library being misused, and everything in the library was nicely encapsulated and had hidden constructs. The project is described in a case study here:

http://www.CraneSoftwrights.com/links/ipepaper.htm

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?


If some XML structure has to be changed, which mechanism (except
regression testing) detects reliably that some module handling this
XML structure isn't fit to do so any more?

I can only think of regression testing. Though if you module is handling the structure in a single template rule using pull, instead of multiple template rules using push, remember that no outside influences can break a working template due to the syntax's side-effect free nature.


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)

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.


I hope this helps.

. . . . . . . . . Ken

--
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Current Thread

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