Here are the answers to oft-received PXSL questions. If your question
isn't answered below, please ask it in the
PXSL Ask-a-Question
section.
Table of contents
General questions
- What is PXSL?
- Does PXSL replace or compete with XML?
- What are your goals for PXSL?
- How does PXSL differ from other XML shorthands?
- Why does PXSL have a macro system?
Using PXSL
- How can I convert existing XML documents into PXSL?
- How does pxslcc handle tabs in PXSL source documents?
General questions
The follwing are questions about the PXSL project, why it is the way
it is, and how it fits into the world. If you want to know something
about the PXSL tools, skip to the next section, "Using PXSL," below.
What is PXSL?
PXSL is the Parsimonious XML Shorthand Language. It provides XML
authors and programmers with a simple, concise syntax that they can
use to create XML documents.
For more advanced users, PXSL offers customizable shortcuts and
sophisticated refactoring tools like functional macros that can
markedly reduce the size and complexity of markup-dense XML documents.
But simplicity and consistency are the top priority. The advanced
features are hidden away until users are ready to use them.
The official PXSL documentation and downloads are located at
http://community.moertel.com/pxsl/ .
(Source code and binary downloads are available.)
Does PXSL replace or compete with XML?
No. PXSL is a shorthand for writing XML. It does not replace or
compete with XML. Rather, it lets you write XML documents by using an
alternative syntax that is more convenient for markup-dense
applications, such as XSLT, Ant build files, or RDF.
What are your goals for PXSL?
PXSL was designed with the following goals in mind:
- PXSL must be open source.
- PXSL must be easy to read, write, and edit.
- PXSL's syntax must be simple, consistent, and concise.
- PXSL must reduce markup and syntactical noise in data-centric XML documents.
- Any feature that we add to PXSL must provide benefits that substantially outweigh the burden that the feature's addition places upon users. (Therefore, advanced features should be invisible until they are called upon to provide compelling benefits.)
- It must be easy to intermix XML and PXSL within a single PXSL document.
- PXSL must be extensible in order to allow sophisticated users and programmers to incorporate application-specific customizations and shortcuts.
How does PXSL differ from other XML shorthands?
There are at least a dozen other shorthands for XML and XML-like languages.
Here are a few:
PXSL differs from these other shorthands in some or all of the following ways:
- PXSL combines simplicity, generality, extensibility, and constrained programmability into one cohesive language that complements rather than competes with XML.
- PXSL lets users intermix PXSL and XML syntax in one document. Users are free to use whichever syntax works best for each portion of their documents. (In other words, PXSL doesn't lock users into its syntax.)
- PXSL scales to the needs of each user. PXSL offers beginning users a simple, easy-to-understand shorthand that they can be productive with immediately. Yet advanced users will find that PXSL provides a rich set of tools for constructing and refactoring complex, data-centric documents. PXSL burdens neither class of users with the other's concerns.
- PXSL can be customized with application-specific shortcuts.
- PXSL has a powerful hygienic macro system that can be used to build complicated document structures safely and conveniently.
Why does PXSL have a macro system?
In short, because the macro system has proven itself to be surprisingly useful. (See, for example,
Refactoring XSLT one-offs with PXSL.)
The long answer is has to do with
XML's design goals, goals 4 and 10 in particular:
- 4. It shall be easy to write programs which process XML documents.
- 10. Terseness in XML markup is of minimal importance.
XML is syntactically noisy in order to make the job of
writing programs that process XML easier. The scales were
tipped to make XML users carry more baggage so that XML implementors
have to carry less. (And this was probably a good decision: If XML
wasn't easy to implement, there would have been few initial
implementations to attract the community of users that have made XML
so popular today.)
This design philosophy carries into many applications that are built
on top of XML (e.g., XSLT). In the same way that XML makes users
write more markup in order to create any given bit of document
structure, many XML-based applications make users create
more document structure in order to express any given bit of
application-specific data. It's a double-whammy.
PXSL, in contrast to XML, was designed with the opposite conviction:
We (the guys creating PXSL) were willing to invest lots of time and
effort in writing complicated parsers and processors, if it meant that
the PXSL user's burden was correspondingly reduced. We wanted to see
how far we could tip the scales in the user's favor.
PXSL's outline-based syntax does a good job of reducing the syntax verbosity that XML imposes, but it doesn't help with markup verbosity that many XML applications impose.
That's what the macros are for. PXSL lets you create small macros that
create verbose application-specific structures for you.
Using PXSL
The following questions are about using PXSL and the PXSL tools,
pxslcc being the most prominent.
How can I convert existing XML documents into PXSL?
Included in the
PXSL source-code distribution is an XSLT
stylesheet called
xsl2pxsl.xsl. It was originally created to
convert XML-based XSLT stylesheets into PXSL (hence its name), but it
works just as well as a general XML-to-PXSL convsion tool. It's imperfect, and its output isn't nearly as crisp and compact as hand-written PXSL, but it's a good starting point, especially if you are migrating an established repository to PXSL.
How does pxslcc handle tabs in PXSL source documents?
It doesn't. It rejects them.
Tabs are fragile, fickle things that often get lost or damaged in transit and mean different things in different computing environments. Does a tab represent four spaces? Eight? Something else? It depends. There is no One Right Way. For this reason,
pxslcc generates an error when it encounters tabs in the layout (indented) portions of documents. (Yes, you
can use tabs inside of text and mixed-content literals.)
The best advice I have is not to embed ASCII TAB characters in your documents. If you must use them, expand them yourself before giving your documents to
pxslcc. That's what the Unix
expand utility is for:
expand -4 myfile.pxsl | pxslcc > myfile.xml