PXSL/FAQs

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:

• DL
• ONX
• PYX
• S(cheme)XML
• SOX (Simple Outline XML)
• Tanga (project seems to have died)
• Terse XML
• XSLScript
• XSLtxt
• YAML (not isomorphic to XML)

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 would 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 among the PXSL sources is an XSLT stylesheet called xsl2pxsl.xsl, written by Bill Hubauer. 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. Its output isn't as crisp and compact as hand-written PXSL, but it's a good starting point 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