gimsieke / epubcheck-xproc Goto Github PK

Parsing of CSS stylesheet fails if encoding is different than UTF-8.

Invoke calabash with

xproc Martin$ calabash -i source=example.xhtml test-css.xpl

results in this output:

26.09.2011 16:26:29 com.xmlcalabash.util.DefaultXProcMessageListener error
SCHWERWIEGEND: file:/xsl/css-parser.xsl:31:err:XTDE1200:Failed to read input file file:/Users/Martin/workspace/epubcheck-xproc/xproc/standard-epub-2-0/OEBPS/stylesheet.css (java.nio.charset.MalformedInputException)
26.09.2011 16:26:29 com.xmlcalabash.util.DefaultXProcMessageListener error
SCHWERWIEGEND: Failed to read input file file:/xproc/standard-epub-2-0/OEBPS/stylesheet.css (java.nio.charset.MalformedInputException)
26.09.2011 16:26:30 com.xmlcalabash.util.DefaultXProcMessageListener error
SCHWERWIEGEND: Failed to read input file file:/xproc/standard-epub-2-0/OEBPS/stylesheet.css (java.nio.charset.MalformedInputException)
26.09.2011 16:26:30 com.xmlcalabash.drivers.Main error
SCHWERWIEGEND: Pipeline failed: net.sf.saxon.s9api.SaxonApiException: Failed to read input file file:/xproc/standard-epub-2-0/OEBPS/stylesheet.css (java.nio.charset.MalformedInputException)
26.09.2011 16:26:30 com.xmlcalabash.drivers.Main error
SCHWERWIEGEND: Underlying exception: net.sf.saxon.trans.XPathException: Failed to read input file file:/xproc/standard-epub-2-0/OEBPS/stylesheet.css (java.nio.charset.MalformedInputException)

In order to enable validation message reporting, the default p:validate-with-relax-ng step needs a report port, just like p:validate-with-schematron.

This one uses a p:exec which invokes 'java': http://www.oxygenxml.com/pipermail/oxygen-user/2010-July/003221.html

Is that portable enough?

What is the canonical way to bind custom pipeline types to java classes, so we can distribute just the class file?

err:XTRE0540:Ambiguous rule match for /html/body[1]/div[1]/p[58]
Matches both "[matches(@Class,'(^|\s)foo(\s|$)')]" on line -1 of
and "[matches(@Class,'(^|\s)bar(\s|$)')]"

Possible solution:
– Don’t write rules for processing elements. Write rules for processing @Class attribute tokens.
– Tokenize each class attribute.
– Process each token

What are the precedence rules for the tokens? The last token’s declarations win? This should translate well to attributes being created by template rules that process each token.

Another consideration: because in XSLT 2, template rules may not be declared to match a string, should css2xsl.xsl create named templates for each token? (<xsl:template name="class-foo">…) Will this capture the different priorities / important declarations?