Commit 5d1b023c authored by Wendell Piez's avatar Wendell Piez

Copy edits

parent 328795b5
......@@ -39,9 +39,10 @@ Since this endeavor is open-ended and everyone's solution will be different, XSw
## Why XSLT
XSLT is a 4GL not a 3GL. As such, it would ideally be regarded as compatible with and complimentary to any 3GL, 4GL or mix. The problem domain addressed by XSLT is the arbitrary, rules-based *transformation* of a tree-shaped data structure, into another such tree-shaped structure. Such structures are typically built as representations of intellectual objects represented using formal notation in documents or files, "tagged" as XML. (They may also persist in systems as "XML document objects" of some nature, not only as text files on disks) From a user's point of view, this ordinarily means there will be a "source file" or "source document", namely a data instance (nominally, an XML or other file of some kind). And there will be an operation to perform, a process to run, which results in the production of "transformation output". This is (again typically) another XML or HTML file or document, representing the changes, translations or embellishments provided to the original by the transformation (or "stylesheet"). By itself, this simple model solves no problems at all. Without specifying what transformation to perform -- without providing a stylesheet -- nothing happens (or nothing very useful). But provide stylesheets, and XSLT becomes a kind of generalized information machine tool, working at any level of scale from very large and copious, to very granular. Among the many uses it can be put to are quite complex translations to help reconcile and align different encoding systems, describing what are (nominally and actually) very different kinds of data.
Because XSLT is specifically designed for the task, it provides many built in features and functionalities specifically to reduce the task overhead ordinarily related to these operations. As a language, XSLT is considered to be verbose, as indeed line for line, it is. But XSLT code bases tend also to be relatively small, because at the level of the transformation itself and its own mappings and operations, its expression is extremely concise and economical. Because it is Turing complete and because it is able, natively, to process its own outputs, XSLT is also, incidentally, capable at least in theory of specifying *any* transformation that can be specified in terms of its data model. Theory aside, it is extremely versatile and extensible.
XSLT is a 4GL not a 3GL. As such, it would ideally be regarded as compatible with and complimentary to any 3GL, 4GL or mix. The problem domain addressed by XSLT is the arbitrary, rules-based *transformation* of a tree-shaped data structure, into another such tree-shaped structure. Such structures are typically presented (where XSLT is used) as representations of intellectual objects encoded using formal notation in documents or files, "tagged" as XML. (They may also persist in systems as "XML document objects" of some nature, not only as text files on disks.) From a user's point of view, this ordinarily means there will be a "source file" or "source document", namely a data instance (nominally, an XML or other file of some kind). And there will be an operation to perform, a process to run, which results in the production of "transformation output". This is (again typically) another XML or HTML file or document, representing the changes, translations or embellishments provided to the original by the transformation (or "stylesheet"). By itself, this simple model solves no problems at all. Without specifying what transformation to perform -- without providing a stylesheet -- nothing happens (or nothing very useful). But provide stylesheets, and XSLT becomes a kind of generalized information machine tool, working at any level of scale from very large and copious, to very granular. Among the many uses it can be put to are quite complex translations to help reconcile and align different encoding systems, describing what are (nominally and actually) very different kinds of data.
Because XSLT is specifically designed for the task, it provides many built in features and functionalities specifically to reduce the task overhead ordinarily related to these operations. As a language, XSLT is sometimes described as verbose, as indeed line for line, it is. But XSLT code bases tend also to be relatively small, because at the level of the transformation itself and its own mappings and operations, its expression is extremely concise and economical. Because it is Turing complete and because it is able, natively, to process its own outputs, XSLT is also, incidentally, capable at least in theory of specifying *any* transformation that can be specified in terms of its data model. Theory aside, it is extremely versatile and extensible.
## XSweet architecture: mix and match your XSLTs
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment