vs.templ

Static template builder for XML, based on pugixml

https://github.com/lazy-eggplant/vs.templ

Science Score: 44.0%

This score indicates how likely this project is to be science-related based on various indicators:

  • CITATION.cff file
    Found CITATION.cff file
  • codemeta.json file
    Found codemeta.json file
  • .zenodo.json file
    Found .zenodo.json file
  • DOI references
  • Academic publication links
  • Committers with academic emails
  • Institutional organization owner
  • JOSS paper metadata
  • Scientific vocabulary similarity
    Low similarity (15.7%) to scientific vocabulary

Keywords

codegen preprocessor pugixml xml xslt
Last synced: 4 months ago · JSON representation ·

Repository

Static template builder for XML, based on pugixml

Basic Info
Statistics
  • Stars: 7
  • Watchers: 1
  • Forks: 0
  • Open Issues: 6
  • Releases: 10
Topics
codegen preprocessor pugixml xml xslt
Created about 1 year ago · Last pushed 7 months ago
Metadata Files
Readme Citation

README.md

[!WARNING]
Documentation is an ongoing effort.

vs.templ is a simple XML preprocessor. Its design objectives are:

  • to be easily embeddable
  • low memory & storage footprint (special builds can make it viable on embedded devices)

It can be used to statically generate XML documents from a template definition and one or more data sources.
Static templates can be seen as simple programs serialized in XML. vs.templ is a virtual machine which can run them.
Input is provided from the data sources (usually XML documents as well), and a new one is returned as output.

You can check out our playground to get familiar with vs.templ capabilities and syntax. If you want a more comprehensive and verbose description, you can check the dedicated documentation.
We also generate doxygen documentation to support developers who want to integrate vs.templ in their own projects.

Quick example

Given an XML data source

xml <items> <item prop-a="Value 1">Text A</item> <item prop-a="Value 2">Text B</item> <item prop-a="Value 3">Text C</item> </items>

and a template

xml <ul> <s:for in="/items/" sort-by="~prop-a" order-by="desc"> <s:item> <li><s:value src="~prop-a"/>: <s:value src="~!txt"/></li> </s:item> </s:for> </ul>

after processing by vs.templ, the final result will be:

xml <ul> <li>Value 3: Text C</li> <li>Value 2: Text B</li> <li>Value 1: Text A</li> </ul>

For more examples, please check the online playground.

Usage

This preprocessor can be used in one of two ways:

As a library

vs.templ is specifically intended to be embedded in other applications.
You can use it either as a dynamic or a static library.
If you want to integrate vs.templ in your own codebase, this is where to start.

Via its CLI

This repo provides a minimal standalone wrapper to access most features offered by this library from command line.

bash vs.templ <template-file> <data-file> [namespace=`s:`]

There is also an alternative format:

bash vs.templ [namespace=`s:`]

with both files added via pipes, like vs.tmpl <(cat template.xml) <(cat data.xml)

vs.templ.js

If you don't want to install vs.templ, there is a standalone wasm/wasi build available in the release information.
To use it just run:

bash bun run ./vs.templ.js [...]

Installation

Check the Makefile. It will work out of the box on most systems.
There are some flags in there you can configure without having to touch Meson directly.

Projects using vs.templ

  • vs the parent project from which vs.templ derived.
  • enance-amamento as templating engine for the imported XML files.
  • vs.http an HTTP server built around vs.templ.

Why?

vs.templ was first developed in the context of vs to express static, yet parametric, components.
While the XML ecosystem is often reliant on XSLT as a preprocessor, this option was quickly dismissed in the parent project for several reasons:

  • The rest of the vs is based on pugixml. The only lightweight XSLT 1.0 implementation which is decently licensed is libxslt based on libxml2.
    Because of that, a trivial integration would have been quite wasteful: an additional serialization and parsing stage is needed to move the tree structure between libraries.
  • The scope of XSLT, even in its very first version was excessive & its syntax just verbose. This is mostly a result of xpath being too powerful of a tool.
  • At some point vs will come with dynamic native components, and the idea is for them to match in syntax and behaviour the extended tags introduced by this preprocessor. A custom implementation is the only way to ensure a seamless integration between the two.

Hence, vs vendors its own XSLT-ish preprocessor.
Still, nothing about its semantics or syntax is directly tied to vs, so I am distributing it as a separate package, hoping it can reach a wider adoption.

To cover further questions, I collected some in a FAQ document.

Owner

  • Name: lazy-eggplant
  • Login: lazy-eggplant
  • Kind: organization

Citation (CITATION.cff)

cff-version: 1.2.0
title: vs.templ
message: >-
  If you use this software, please cite it using the
  metadata from this file.
type: software
authors:
  - name: lazy-eggplant
  - given-names: karurochari
    affiliation: lazy-eggplant
    email: public@karurochari.com
repository-code: 'https://github.com/lazy-eggplant/vs.templ'
url: 'https://lazy-eggplant.github.io/vs.templ/'
abstract: 'Static template builder for XML, based on pugixml.'
keywords:
  - xslt
  - xml
  - preprocessor
  - pugixml
license: BSD-3-Clause

GitHub Events

Total
  • Create event: 15
  • Commit comment event: 2
  • Release event: 11
  • Issues event: 39
  • Watch event: 6
  • Delete event: 5
  • Issue comment event: 17
  • Push event: 405
  • Pull request event: 6
Last Year
  • Create event: 15
  • Commit comment event: 2
  • Release event: 11
  • Issues event: 39
  • Watch event: 6
  • Delete event: 5
  • Issue comment event: 17
  • Push event: 405
  • Pull request event: 6

Committers

Last synced: 9 months ago

All Time
  • Total Commits: 166
  • Total Committers: 6
  • Avg Commits per committer: 27.667
  • Development Distribution Score (DDS): 0.434
Past Year
  • Commits: 166
  • Committers: 6
  • Avg Commits per committer: 27.667
  • Development Distribution Score (DDS): 0.434
Top Committers
Name Email Commits
karurochari K****i 94
karurochari n****e 34
checkroom c****m@l****n 26
checkroom p****c@k****m 6
Karuro Chari k****i 5
karurochari k****i@m****m 1
Committer Domains (Top 20 + Academic)

Issues and Pull Requests

Last synced: 4 months ago

All Time
  • Total issues: 23
  • Total pull requests: 6
  • Average time to close issues: 10 days
  • Average time to close pull requests: about 6 hours
  • Total issue authors: 1
  • Total pull request authors: 2
  • Average comments per issue: 0.39
  • Average comments per pull request: 0.0
  • Merged pull requests: 5
  • Bot issues: 0
  • Bot pull requests: 2
Past Year
  • Issues: 23
  • Pull requests: 6
  • Average time to close issues: 10 days
  • Average time to close pull requests: about 6 hours
  • Issue authors: 1
  • Pull request authors: 2
  • Average comments per issue: 0.39
  • Average comments per pull request: 0.0
  • Merged pull requests: 5
  • Bot issues: 0
  • Bot pull requests: 2
Top Authors
Issue Authors
  • KaruroChori (24)
Pull Request Authors
  • KaruroChori (4)
  • dependabot[bot] (2)
Top Labels
Issue Labels
enhancement (11) bug (4) CI (3) wasm-sandbox (3) documentation (2) help wanted (1)
Pull Request Labels
dependencies (2) github_actions (2)