PAR/Pattern generator

[skreutzer]

This repository is collecting the PARs as content/files themselves, but it has been tedious to write the PARs elsewhere and migrate them over here from many publication feeds/sources, especially as they lack the technical, operational semantics of a data format if done via regular plain-text editors. Therefore, this project is about building a PAR generator/form, and ideally even as an universal app which can be used to instantiate/create any kind of pattern from a configurable pattern template.

[skreutzer]

pattern-template-form-generator

[holtzermann17]

@skreutzer this looks very promising, thanks. Please add README explaining how to use it. I opened form_generator_1.xsl in a web browser but that didn't work!

[skreutzer]

These XSLT-Stylesheets (XSLT = eXtensible Stylesheet Language Transformation, XML-based), they always work the same. For a given XML-based input file, the stylesheet can be applied onto it in order to transform it into an output file. That task is performed by a XSLT processor (program or programming library). On most operating systems, there are a whole bunch of them on board, and many programming languages come with them on-board. If not, third-party libraries can be used. The sad, unfortunate part is that this universal capability is rarely available to regular users as a standalone program, and despite in the early Web during the Semantic Web days, there were promising efforts to make them part of Web architecture (in fact, browsers for several reasons likely to this day might have such a processor integrated), now the trend is to get rid of them entirely, so the Web can be more broken, so people become more dependent on the big browser vendors.

Anyway, what operating system are you using or people who want to run the generator themselves? It's already useful to go with the generated result, but of course, if more pattern templates get produced, maybe one wants to have the option to generate the forms for each of them, maybe in different styles (Engelbartian ViewSpecs? White label customized variants?), or maybe using it on personal pattern templates that aren't contributed to this repository.

Usually I use a very simple program of mine that does nothing but wrapping the Java XSLT processor into an executable standalone tool, which then can run on the popular operating systems if users have a Java JRE installed (which is often the case, and be it because of LibreOffice or similar). To add this to the repo, I could, as with the other packages, add a little setup/packaging script, which compiles these dependencies and bundles them together into a downloadable, installable release.

One simple way is to use the onboard XSLT processor in Web browsers (if still present) by adding the line

<?xml-stylesheet type="text/xsl" href="form_generator_1.xsl"?>

to the pattern template files $/templates/pattern-template-par.xml and $/templates/pattern-template-peeragogy.xml after $/form_generator_1.xsl has been moved into the $/templates/ subdirectory (for some reason, relative paths don't seem to be supported), so if these *.xml files are opened in the browser, it's expected to perform a temporary transformation, and if lucky with your browser of choice, maybe you can do a "Save as" to save the generated result as an *.xhtml file for future use. I never add styleheet references to XML files however, as the user may choose many different ones of them, so there's no point in selecting a single layout/transformation/stylesheet and "lock that in", as it's kind of the default with CSS and Web layout for HTML where the server tries to impose how things are supposed to look/behave like, despite the XML/HTML is about semantic meaning and document structure, not about the visual representation.

If it's only about XSL-Transformations in isolation and less about other, more general considerations in regard of the XML toolchain/"infrastructure", other typical solution candidates would be xmlstarlet or xsltproc. Many of the larger XML toolchain packages expose XSL transformation capabilities to the command line, and of course it's part of the big, expensive, commercial offers as well.

There's also the option of us developing a GUI standalone variant of our own, and ideally it could even be expanded into a smart approach to determine the input format semantically and manage corresponding, available stylesheets for ViewSpecs in some kind of document processing or hypertext system, if that's of interest. .NET (and therefore likely Mono too) comes with its own XSLT processors (likely available via PowerShell, but then, one wouldn't have that installed out of the box either), so do Python, PHP, and everything else, maybe sometimes it's the same code/component integrated in multiple places, just as the worse kind of operating systems don't have a way to share such capability across applications and programming languages.

There's also the option to get rid of the XSLT stylesheet altogether and simply hard-code a transformation in a custom standalone program. Especially with the downsides of me using the Web browser as programming stack for the pattern input form and a Quine-like approach for saving, it's already stressing the limits as browsers don't like any of that because it escapes the sandboxing needed for security, which is also the problem for loading existing patterns to edit them according to their template (old or new?). Surely a common workaround could be to put it on a server, which is the road to get stuck and trapped in the Web model and SaaS dependencies, where one can't write simple pattern files any more for no good reason other than a domain has vanished or something. Therefore this might be a quick prototype anyway, and the way to go could be to start a native variant of what's currently in the repo.

Wonder if that was helpful. I don't mind to document whatever is of use in a README or describe in detail or help people to reproduce the steps on whatever environment/setup they're using, but the question is what should exactly be put down, by avoiding turning the README into an exploration of XSLT and the XML toolchain/infrastructure, which is only necessary because some of the popular operating systems are terrible with providing/exposing even these most basic capabilities.

[skreutzer]

There might even be a whole bunch of "online" XSLT processor services, but don't see the point as many are already natively installed or readily available/installable. In general, these are very, very common components and tools for working with structured text-oriented data/formats.

[holtzermann17]

Thanks for the explanation!

Here's my sketch of how the pattern generator might fit into a broader "dashboard" functionality.
I added one more mockup of one more box, so that people can easily create their own data-gathering mechanisms, without writing XML directly.

[skreutzer]

Here's something on XSLT.