Git Product home page Git Product logo

geekodoc's Introduction

GeekoDoc

Validating GeekoDoc

What is GeekoDoc?

GeekoDoc is a RELAX NG schema and a subset of DocBook 5. It restricts the content model of some elements and attributes to make it easier to write documents.

Valid GeekoDoc documents are also valid DocBook 5 documents.

GeekoDoc Versions

GeekoDoc comes in two versions that are currently very similar. Their main difference is that GeekoDoc 2 restricts xml:id attributes to a more SEO-friendly subset of characters. More changes are to be expected in the future.

In general, we recommend using GeekoDoc 2 for all new projects.

  • GeekoDoc 1: available via the URI urn:x-suse:rng:v1:geekodoc-flat

  • GeekoDoc 2: available via the URI urn:x-suse:rng:v2:geekodoc-flat

Additional versions of GeekoDoc

  • New, versioned URIs:

    • Available for GeekoDoc 1 and GeekoDoc 2

    • General syntax: urn:x-suse:FORMAT:VERSION:SCHEMA

      • FORMAT: can be rnc or rng

      • VERSION: can be v1 or v2

      • SCHEMA: geekodoc-flat

    • Includes the following URIs:

      urn:x-suse:rnc:v1:geekodoc-flat
urn:x-suse:rng:v1:geekodoc-flat
urn:x-suse:rnc:v2:geekodoc-flat
urn:x-suse:rng:v2:geekodoc-flat

  • Old, unversioned URIs (do not use for new projects):

    • Only available for GeekoDoc 1

    • General syntax: urn:x-suse:rng:FILE

    • Includes the following URIs:

      urn:x-suse:rng:geekodoc5.rnc
urn:x-suse:rng:geekodoc5-flat.rnc
urn:x-suse:rng:geekodoc5.rng
urn:x-suse:rng:geekodoc5-flat.rng

Using GeekoDoc with DAPS

To use GeekoDoc for validating your XML documents with DAPS, add the following line in your ~/.config/daps/dapsrc and replace <URI> with one of the URIs above:

DOCBOOK5_RNG_URI="<URI>"

It is possible to add the previous line into a DC file.

Creating Flat GeekoDoc

Creating the flat GeekoDoc schema requires the rnginline tool from https://github.com/h4l/rnginline/.

Use one of the following methods to install rnginline:

  • Install from an RPM package

  • Install it in a Python virtual environment

Installing rnginline from RPM Package on openSUSE

The following procedure can be used for the latest openSUSE Leap release:

  1. Add the devel:languages:python repository:

    • for openSUSE Leap:

      sudo zypper ar https://download.opensuse.org/repositories/devel:/languages:/python/openSUSE_Leap_\$releasever/devel:languages:python.repo

    • for openSUSE Tumbleweed:

      sudo zypper ar https://download.opensuse.org/repositories/devel:/languages:/python/openSUSE_Tumbleweed/devel:languages:python.repo

  2. Install the package:

    sudo zypper in python3-rnginline

The executable can be found in /usr/bin/rnginline.

Installing rnginline using a Python Virtual Environment

  1. Install the RPM packages python3-devel, libxml2-devel, and libxslt-devel. On openSUSE, run:

    sudo zypper in python3-devel libxml2-devel libxslt-devel

  2. Create a Python3 virtual environment:

    python3 -m venv .env3

  3. Activate the virtual environment:

    source .env3/bin/activate

    You should see a changed prompt (look for the (.env3) part).

  4. Install the rnginline library from PyPi:

    pip install rnginline

The executable can be found in .env3/bin/rnginline.

Creating a Flat GeekoDoc Schema

  1. Update your GitHub repository.

  2. Run ./build.sh.

  3. Find the built schema in dist/geekodoc/rng/.

Installing it on Debian/Ubuntu

To install GeekoDoc on Debian or Ubuntu from scratch, do the following steps:

  1. Create a virtual Python environment with rnginline.

  2. Create a Flat Geekodoc Schema

  3. Copy the XML catalog file to the standard location:

    cp -v catalog.d/geekodoc.xml /etc/xml/geekodoc.xml

  4. Adapt the paths in the catalog file:

    sed -i 's#"\.\./#"/usr/share/xml/#' /etc/xml/geekodoc.xml

  5. Create the target directory and copy the schema files:

    mkdir -p /usr/share/xml/rng
cp -v geekodoc/rng/*-flat.rn? /usr/share/xml/rng

  6. Adapt the main XML catalog:

    sudo xmlcatalog --noout --add delegateSystem \
    https://github.com/openSUSE/geekodoc/ /etc/xml/geekodoc.xml /etc/xml/catalog
sudo xmlcatalog --noout --add delegateURI "urn:x-suse:rng:" \
    /etc/xml/geekodoc.xml /etc/xml/catalog
sudo xmlcatalog --noout --add delegateSystem "urn:x-suse:rng:" \
    /etc/xml/geekodoc.xml /etc/xml/catalog

  7. Test the installation:

    xmlcatalog /etc/xml/catalog \
    https://github.com/openSUSE/geekodoc/raw/master/geekodoc/rng/geekodoc5-flat.rnc \
    urn:x-suse:rng:geekodoc5.rng \
    urn:x-suse:rnc:v1:geekodoc-flat \
    urn:x-suse:rng:v1:geekodoc-flat \
    urn:x-suse:rnc:v2:geekodoc-flat \
    urn:x-suse:rng:v2:geekodoc-flat

    You should get something like this:

     /usr/share/xml/geekodoc/rng/geekodoc5-flat.rnc
 No entry for SYSTEM urn:x-suse:rng:geekodoc5.rng
 /usr/share/xml/geekodoc/rng/geekodoc5-flat.rng

Supporting Vim

To work with RELAX NG and vim, you need a .vim file. This file is generated from the flat RNG schema.

To extract all relevant information for Vim, use the rng2vim tool from https://github.com/jhradilek/rng2vim.

rng2vim geekodoc5-flat.rng geekodoc

The file geekodoc.vim can be used with vim.

Creating an Archive for Open Build Service

If you develop on GeekoDoc and would like to create an archive file for OBS, use the following steps:

  1. Configure first the bzip command (this has to be done only once):

    git config tar.tar.bz2.command "bzip2 -c"

  2. Create an archive and save it in your OBS directory (OBSDIR):

    git archive --format=tar.bz2 --prefix=geekodoc-2.0.1/ -o <OBSDIR>/geekodoc-2.0.1.tar.bz2 HEAD

geekodoc's People

Contributors

fsundermeyer avatar taroth21 avatar tomschr avatar vogtinator avatar

Stargazers

avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

jcayouette vikas-lamba sitedata

geekodoc's Issues

Add list elements in taskprerequisites

According to #1 (comment) it seems we didn't think of add lists inside taskprerequisites. Maybe we should. (Related to #1)

Reported by @sknorr , thanks!

Thinking of this, maybe we should consolidate it. What about admonitions? Should these also included?

Expand test cases to include as many of our actual documents as possible

I was just wondering -- if we built and sync'd bigfiles to susedoc.github.io and had Travis download them as part of the Geekodoc test cases, we could immediately see if & how much breakage any change of Geekodoc is creating.

That would aid a lot in estimating whether a particular change that seems like a good idea in theory is also a good idea in practice.

In the past I sometimes did that manually (i.e. installing the new Geekodoc version and running for dc in DC-*; do daps -d $dc validate; done) but that really does not scale.

This would need two primary changes:

  • Addition of a bigfile build to openSUSE/doc-ci's travis.sh
  • Addition of a couple of wget commands to the test cases of this repo

geekodoc only: Restrict IDs to only alphanumeric characters + "-"

For SEO reasons, we have decided to abolish all uses of . and _ characters in our DocBook IDs and replace them with -.

However, the Geekodoc schema currently allows IDs with . and _ characters in them, so that is not ideal in terms of editing support against our accumulated 100+ years of muscle memory creating IDs with . and _.

thead and other table elements allow xml:id

GeekoDoc 1.0.1 already disallows xml:id on row and entry but preety much all other table-related elements still allow xml:ids even though they should not:

  • thead
  • colspec
  • tgroup
  • tbody

(List is not exhaustive, just the few that I immediately thought of and tried.)

Allow attributes in link, i.e. <link os="..."/>

Please allow profiling attributes within link (i.e. stuff like os, condition, etc.).
Usage example:

For an overview of the documentation available for your product and the
latest documentation updates, refer to
<link os="sles;sled" xlink:href="http://www.suse.com/doc"/><link os="osuse"
xlink:href="https://doc.opensuse.org/"/>.

This is a lot more elegant than the equivalent you have to use right now:

For an overview of the documentation available for your product and the
  latest documentation updates, refer to
  <phrase os="sles;sled"><link xlink:href="http://www.suse.com/doc"/></phrase><phrase
os="osuse"><link xlink:href="https://doc.opensuse.org/"/></phrase>.

Content model of step is not determinist 

daps --force -d DC-susemanager-advanced-topics online-docs
[...]
/data/git/doc-susemanager/build/susemanager-advanced-topics/online-docs/set_en_bigfile.xml:-1:
validity error : Content model of step is not determinist: ((para | formalpara) ,
(important | note | tip | warning | itemizedlist | orderedlist | simplelist |
variablelist | calloutlist | figure | informalfigure | table | informaltable |
blockquote | bridgehead | example | screen | literallayout | remark | para |
formalpara | indexterm)* , substeps* , (para | formalpara | screen | remark |
figure | informalfigure | orderedlist | itemizedlist | simplelist)*)

Restrict <result> element

As the result element has a broad content model, we should allow only certain elements. The current list involves:

  • para, formalpara
  • screen
  • orderedlist, itemizedlist, simplelist
  • figure, informalfigure
  • remark

ITS tag set is not supported by GeekoDoc

The ITS tag set allows setting translation properties that can be read by itstool (we already use this tool to translate openSÜSE). The main reason I am interested in having this tag set available is that it allows for the its:translate="yes|no" attributes.

Investigate additional Schematron Rules for GeekoDoc

In openSUSE/suse-doc-style-checker#117, I raised the question if a Schematron schema could be useful for SDSC. The same question can be asked for GeekoDoc as well.

A Schematron schema can be used in two ways:

  • Embedded
    Schematron rules are embedded inside the RNG schema.
  • Separate
    Schematron rules are collected outside in a different file (extension .sch). They are independant of the existing GeekoDoc RNG.

The validation procedure would be different:

  • Validation with embedded Schematron rules
    The validation with Schematron would be an integral part. In other words, after structural validation
    the rule-based validation process would be performed. Both can't be separated.
  • Validation with separate Schematron schema
    The validation with a separate Schematron schema would be step-wise. First step would be always
    the structural validation with RNG. If wanted (or needed), additional validation can be performed
    with Schematron. Both validation processes can be separated.

Rick Jelliffe, the inventor of Schematron, describe the language as "a feather duster to reach the parts other schema languages cannot reach". ;-)

Benefits

  • Additional checks which cannot be expressed by RNG.
  • Relationship conditions don't need to be checked in SDSC.
  • Kind of structural quality checks (are there any lonely sections? Procedure with a single step?)
  • Conformance checks (IDs should adhere to a certain pattern?)
  • Schematron validation step can be optional or imperative depending on our definition of validation.
  • Additional validation step can be included into DAPS gradually.

Schematron Versions

Currently, there are two versions of Schematron:

  • ISO-Schematron (published Mai 2006)
    the de-facto standard of Schematron. The new namespace http://purl.oclc.org/dsdl/schematron.

  • Schematron 1.5 (published 2001)
    The old reference implementation in pure XSLT. The namespace is http://xml.ascc.net/schematron/.

Tools

Schematron validation are supported by:

  • xmllint and option --schematron.
  • The Python library lxml, see http://lxml.de/validation.html#id2
  • Jing supports Schematron 1.5. Implementation is partely XSLT and partely Java.

See also

Personal

From my perspective, I prefer the separate Schematron schema (assuming all is possible, feasible, or useful). It seems, this doesn't introduce too many changes and gives greater flexibility.

I see it more as a "conformance and consistency" check rather than a hard validation. Of course, the rules shouldn't bother our writers too much.

Maybe we should also (re?)think about our definition of "validity/validation".

--

Update: List of Checks

Hard Rules

  • Import/check against the rules from docbook.sch (upstream DocBook).
  • Check for spaces in xml:id
  • Check for more than 1 step inside a procedure.
  • Check for more than 1 member inside a simplelist.

Soft Rules

  • Check for more than 1 listitem inside orderelist or itemizedlist.
  • Check for more than 1 varlistentry inside variablelist.
  • Check if you have more than 10 steps inside a procedure.
  • Check for a title inside admonition elements (note, tip, warning).
  • Check for specific rules following xml:id attributes.
  • Check for lonely sections(?)

@sknorr I've separated the discussion in SDSC from the GeekoDoc aspect. Feel free to comment. :)

Move Novdoc into a maintenance Branch

Problem Description

As Novdoc is considered obsolete, we should adapt the repository structure.

Expected Behaviour

Remove all Novdoc related files or move them into a specific maintenance branch.

Reduce content model of replaceable

replaceable allows the following nested content:

alt, annotation, co, date, emphasis, firstterm, footnote, foreignphrase, glossterm,
indexterm, inlinemediaobject, link, phrase, quote, remark, subscript, superscript,
trademark, xref,
text

i'd suggest to reduce that to just emphasis, phrase, text.

Missing mediaobject in cover

Problem

The element cover is missing mediaobject.

Solution

The content model for cover should be changed to:

db.cover.contentmodel = db.mediaobject+

For the time being, the cover and mediaobject elements are only needed for logos of the best practices guides.

Restrict the Possible Values in format Attribute

Problem Description

Currently, the format attribute in our GeekDoc is used from the included DocBook 5 schema. The DocBook 5 schema defines the datatype of format as simple text.

However, in contrast with the former DocBook 4 DTD, this has been changed. The older version allowed only a specific list, for example "PNG".
The problem is, if you add "png" instead of "PNG" our stylesheets handle the output differently.

Proposed Solution

Restrict the allowed values of the format attribute to:

db.format.enumeration =
     ## Allowed formats for SUSE documentation
     ("DIA" | "EPS" | "FIG" | "ODG" | "PDF" | "PNG" | "SVG" )

novdocx-core.rnc is missing

novdocx-core.rnc is included by novdocxi.rnc but is neither included in this repo nor generated via Makefile nor installed by the spec file.

Allow sections

Problem

Currently, Geekodoc only allows sectX elements. @sknorr suggested to allow section elements too.
The section element is needed for the HOS documentation.

Solution

(Re)enable db.section pattern.

Enforce para as first child in step

Problem Description

The step element contains lots of elements which could lead to "strange" combination. From a styleguide perspective, we want to have a para element as a first child.

Expected Behaviour

Geekodoc allows only a para element as a first child. After this para, other elements are possible.

Original bug from openSUSE/daps#478

Support for "section"

GeekoDoc (like NovDoc) does not support the <section/> tag that is used in the release notes of both SLE (still DB4-based) and openSUSE (already DB5-based). Given how deeply entrenched the section tag is in our release notes tooling, we probably will not switch to using sect1/2/3/4/5 tags.

Given the complicated availability situation of the GeekoDoc schema, that creates some validation issues for me that ultimately mean that I can't use GeekoDoc in production anywhere:

  • GeekoDoc is not part of any relevant build service project (i.e. not in Leap 42.2, not in SLE 12 SP2), so I can't put the requirement for GeekoDoc into any DC files.
  • Release notes do not validate with GeekoDoc, so I can't put a requirement for it in my dapsrc either

And, then, on the virtues/non-disadavantages of section:

  • section might be helpful in creating more re-usable documentation, since it can be nested within other sections (unlike sect1/2/3/4/5 where order is important).
  • If we are introducing Schematron validation, then checking section would still not be an issue.

So, section support, is it in the cards?

Create semi-official XML Schema

Visual Studio Code with IBM's XML extension allows using XSD but not RNG. Could an (approximate) XSD version of the schema be provided as well?

Allow affiliation inside author

Problem

The author doesn't allow information about affiliation. This is needed for SUSE Best Practices.
(Reported by @chabowski).

Solution

@sknorr and I agreed that we need the following content model:

affiliation ::= (jobtitle | orgname | (jobtitle & orgname))

Example

<author>
    <personname>
     <firstname>Tux</firstname>
     <surname>Penguin</surname>
    </personname>
    <email>[email protected]</email>
    <affiliation>
     <jobtitle>Ice breaker</jobtitle>
     <orgname>Icelandic Corporation Inc.</orgname>
    </affiliation>
</author>

Reduce content model of command

Problem Description

In version 1.0.2.1 of GeekoDoc, command allows the following child elements:

alt, annotation, date, emphasis, firstterm, footnote, foreignphrase,
glossterm, indexterm, inlinemediaobject, link, phrase, quote, remark,
replaceable, subscript, superscript, trademark, xref.

This is too broad, we need a reduced content model.

Expected Behaviour

Reduce it to emphasis(?), phrase, replaceable

Outdated Schematron Rules Give Errors

Problem

Validation with the DocBook 5.1 with oXygen leads to this error message:

 cvc-complex-type.3.2.2: Attribute 'name' is not allowed to appear in element 's:pattern'.

Reason

This is an error from the s:pattern element. The rule has to be rewritten:

<s:pattern name="foo"> ... </s:pattern>
<s:pattern>
   <s:title>Foo</s:title>
   ...
</s:pattern>

Reported by Joseph.

Remove procedure from tables

Problem Description

The element procedure appears in table and informaltable.

This was discussed on doku-intern on Jun 8th, 2018.

Expected Behaviour

Geekodoc does not have procedure in table and informaltable anymore.

Update Novdoc/GeekoDoc to disallow screen in entry

From @sknorr on December 9, 2015 18:31

Screens often need quite a bit of space. When they are nested inside a table they most often don't get that space.
We could do this via the Style Guide (informal) or via the DTD (formal).

Not sure if anyone else agrees with the latter approach... @tomschr, what do you think?

Copied from original issue: openSUSE/suse-xsl#198

Unorthodox book structures are now legal

Novdoc prevented book structures like:

book id=A
  - part
  - preface
  - part
  - chapter
  - part

It would only allow structures like:

book id=B
  - preface
  - chapter
  - part
  - part
  - part

Geekodoc allows both and imo it should only allow the structure of book B.

Allow Lowercase Values in format Attribute

Problem

Currently, the format attribute allows values like "PNG", "JPG", and others. To support writers, the lowercase variant should also be available.

Solution

Add lowercase strings to the db.format.enumeration pattern.

Related to #24

Reduce number of files in package

The package geekodoc is somewhat unnecessary large because it contains RNCs/RNGs that are pretty much only used to develop GeekoDoc.

Package content:

/etc/xml/catalog.d/geekodoc.xml
/usr/share/licenses/geekodoc
/usr/share/licenses/geekodoc/LICENSE
/usr/share/xml/geekodoc
/usr/share/xml/geekodoc/rng
/usr/share/xml/geekodoc/rng/ChangeLog
/usr/share/xml/geekodoc/rng/Makefile           # can probably be removed
/usr/share/xml/geekodoc/rng/README.md
/usr/share/xml/geekodoc/rng/docbookxi.rnc      # can probably be removed
/usr/share/xml/geekodoc/rng/docbookxi.rng      # can probably be removed
/usr/share/xml/geekodoc/rng/geekodoc5-flat.rnc
/usr/share/xml/geekodoc/rng/geekodoc5-flat.rng
/usr/share/xml/geekodoc/rng/geekodoc5.rnc      # can probably be removed
/usr/share/xml/geekodoc/rng/geekodoc5.rng      # can probably be removed
/usr/share/xml/geekodoc/rng/transclusion.rnc   # can probably be removed
/usr/share/xml/geekodoc/rng/transclusion.rng   # can probably be removed
/usr/share/xml/geekodoc/xsl                    # can probably be removed
/usr/share/xml/geekodoc/xsl/sch-fix.xsl        # can probably be removed

Package content for NovDoc:

/etc/xml/catalog.d/novdoc.xml
/usr/share/licenses/novdoc
/usr/share/licenses/novdoc/LICENSE
/usr/share/xml/novdoc
/usr/share/xml/novdoc/dtd
/usr/share/xml/novdoc/dtd/CATALOG     # why is this necessary if we already have novdoc.xml?
/usr/share/xml/novdoc/dtd/novdocx.dtd
/usr/share/xml/novdoc/dtd/novdocxi.dtd
/usr/share/xml/novdoc/dtd/novell.ent
/usr/share/xml/novdoc/dtd/productspec.dtd
/usr/share/xml/novdoc/rng
/usr/share/xml/novdoc/rng/Makefile            # can probably be removed
/usr/share/xml/novdoc/rng/novdocx-core.rnc
/usr/share/xml/novdoc/rng/novdocx-core.rng
/usr/share/xml/novdoc/rng/novdocx.rnc         # can probably be removed
/usr/share/xml/novdoc/rng/novdocx.rng         # can probably be removed
/usr/share/xml/novdoc/rng/novdocxi-flat.rnc
/usr/share/xml/novdoc/rng/novdocxi-flat.rng
/usr/share/xml/novdoc/rng/novdocxi.rnc        # can probably be removed
/usr/share/xml/novdoc/rng/novdocxi.rng        # can probably be removed
/usr/share/xml/novdoc/rng/novell.ent
/usr/share/xml/novdoc/tests                   # can probably be removed
/usr/share/xml/novdoc/tests/article-admons.xml # can probably be removed
/usr/share/xml/novdoc/tests/article-base.xml  # can probably be removed
/usr/share/xml/novdoc/tests/novdocx.dtd       # can probably be removed
/usr/share/xml/novdoc/tests/run-tests.sh      # can probably be removed

Empty <xref/> does not trigger a warning

I inserted an empty <xref/> element in the text (which I forgot to fill with a linkend attribute). When validating the document, GeekoDoc did not complain about the empty <xref/> element . I only spotted it by accident. IMHO, GeekoDoc should warn about empty <xref/> elements.

Forbid xml:id on remark

Not quite sure if that is really possible but it would be great if we could just forbid xml:id attrs on <remark/> tags in GeekoDoc. I will (in shah Cthulhu) also add some code to the style checker regarding this -- if this can be fixed in GeekoDoc, I can do that just for elements nested within remark, otherwise I'd do it for both remark and elements nested within.

Forbid xml:id on row and entry

Problem

The xml:id attribute is allowed on row and entry elements. This shouldn't be the case.
(reported by @sknorr)

Solution

Remove the xml:id attribute from row and entry.

Make sure GeekoDoc is available in OBS/IBS, so we can use it from DC files

We are currently holding off on putting the GeekoDoc schema in our DC files, because it is not available in OBS. Instead, we are relying on all our editors to install GeekoDoc on their machines on their own.

This makes it harder for new team members and external editors (e.g. for AY or OBS docs) to create GeekoDoc-compliant documentation.

formalpara can be used as first element of an admon

In Geekodoc, you can currently use formalpara as the first element of an admon:

<important>
  <formalpara><title>bla</title><para>blub</para></formalpara>
</important>

or

<important>
  <title>haha jk</title>
  <formalpara><title>bla</title><para>blub</para></formalpara>
</important>

Neither construct makes any sense to me. Could we restrict this?

cf. the online-docs failure of the CAP guide, develop@4e27a3e6.

Reduce content model in screen

Problem Description

This is valid:

<screen><literal># eon resource-update &lt;RESOURCE_ID&gt; [...]</literal></screen>

(This is autoconverted stuff from the Cloud docs, that is the only reason why it exists...)

Expected Behavior

It should not be valid because it makes no sense and can create Novdoc conversion issues.

Allow <mediaobject> only in <figure> and <informalfigure>

In one of our XML files, I found the following code:

 <mediaobject>
  <imageobject>
   <imagedata width="50%" fileref="hawk-batchmode-show.png"/>
  </imageobject>
 </mediaobject>

It can currently be validated with GeekoDoc and works as expected in PDF (and also in EPUB output). However the question is if we really want to allow this in GeekoDoc (without <figure/> or <informalfigure/> and also without the role attribute that we usually use?

thead + xml:id is allowed

Problem Description

<thead xml:id="...">

This is valid

Expected Behaviour

It shouldn't be valid -- there is no reason to xref a thead (well, barring transclusions) and there is no way to generate a title from one. Also creates issues with Novdoc conversion currently.

Disallow empty sections

The following is currently allowed in Geekodoc:

<section>
  <title>Some title</title>
 </section>

(Same issue for <sect[1-5]/>)

Imo, sections should always contain at least either:

  • actual content (<para/>/...)
  • a subsection

I wouldn't make a para or similar mandatory if there is a subsection, even if that is the ideal case. But in the past, doing so has only led authors to include empty <para/> tags that then created layout issues to circumvent that rule.

Output XSLT stylesheet from Schematron validation

Problem Description

For debugging purposes, it would be good to store the XSLT stylesheet after validation. The lxml.de page refers to this:

setting store_xslt to True will result in the validation XSLT document tree being kept;
it can be retrieved through the validator_xslt property.

From http://lxml.de/validation.html#id2

Expected Behaviour

  • The help contains an additional option --store-xslt XSLT
  • The script saves the validation XSLT document into a specific file.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.