RE: calling for xproc pain points, requested features, etc

Good thought. I was falsely assuming the xquery version declaration was
required. I was also falsely assuming that xml decl is required.



There are ways around. One could default to one of both (dictated by rec),
and handle the other with an optional mime type indication. I don’t think a
fail-safe mechanism is possible, but if it could catch 60% of common cases,
that would already mean a lot, don’t you think? That is what all the
short-hands and syntactic sugar is all about, right?



Cheers,

Geert



*Van:* Michael Sokolov [mailto:sokolov@ifactory.com]
*Verzonden:* zaterdag 7 januari 2012 6:34
*Aan:* Geert Josten
*CC:* Philip Fennell; Jostein Austvik Jacobsen; xproc-dev@w3.org
*Onderwerp:* Re: calling for xproc pain points, requested features, etc



Magic is flashy but unreliable; what if you want to accept javascript some
day?  xquery and javascript could be indistinguishable:

1 + 1

is valid in both

On 1/6/2012 4:42 PM, Geert Josten wrote:

I’d prefer magic. One would need only a few detection rules to determine
the type. Text starting with ‘xquery version’? XML starting with an element
in xsl or xproc namespace? Though mime-typed import would already be a
great improvement..



;-)



*Van:* Philip Fennell [mailto:Philip.Fennell@marklogic.com]
*Verzonden**:* vrijdag 6 januari 2012 15:46
*Aan:* Geert Josten; Jostein Austvik Jacobsen; xproc-dev@w3.org
*Onderwerp:* RE: calling for xproc pain points, requested features, etc



+1 from me too. That’s a good idea, it’s something we’ve talked about in
the Forms Working Group too for getting access to custom functions to
beused in XForms’ XPath expressions.



Perhaps we could have a more generalised p:import element and you have a
type attribute with the appropriate mime-type (a bit like HTML’s script
element) where you indicate explicitly what language you are importing:



<p:import href="lib/test.xsl"/>
                                                            <!—Assumed
XProc -->

<p:import href="lib/test.xsl" type="application/xslt+xml"/>
<!—XSLT -->

<p:import href="lib/test.xsl" type="application/xquery"/>
<!—XQuery -->



I believe that there’s no specific registration for an XProc MIME Media
Type but if anything I suppose it would be application/xproc+xml.





Regards



Philip



*From:* Geert Josten [mailto:geert.josten@dayon.nl]
*Sent:* Friday, January 06, 2012 1:34 PM
*To:* Jostein Austvik Jacobsen; xproc-dev@w3.org
*Subject:* RE: calling for xproc pain points, requested features, etc



+1 if it allows importing XQuery libraries as well.. ;-)



Grtz



*Van:* Jostein Austvik Jacobsen [mailto:josteinaj@gmail.com]
*Verzonden:* vrijdag 6 januari 2012 11:49
*Aan:* xproc-dev@w3.org
*Onderwerp:* Re: calling for xproc pain points, requested features, etc



I like pretty much all the suggestions on the Usability and XprovVnext wiki
pages!



There's one request I have though (more of a 'revolutionary' than a 'fix
whats broke' thing): I'd like to be able to reuse my XSLT2 stylesheet
functions in from the XPath expressions in my XProc pipelines.



To do this today, I pass the function parameters as parameters to a p:xslt
step, which has an inlined XSLT2 stylesheet that imports the stylesheet
containing the xsl:function, passes the parameters to the xsl:function and
then outputs the result in a c:result element. Then I retrieve the result
in my XProc pipeline by reading the result document from the p:xslt steps
result port.



If I could somehow just do something simliar to this, it would be awesome:



<p:pipeline ... xmlns:myns="...">

    <p:import-xslt-functions href="my-stylesheet-functions.xsl"/>

    <p:variable name="myVar" select="myns:myFunction(//paragraph,
'other-stuff')"/>

    ...

</p:pipeline>





Regards

Jostein





2012/1/6 Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de>



On 2012-01-06 05:18, Michael Sokolov wrote:

On 1/5/2012 9:46 PM, Imsieke, Gerrit, le-tex wrote:


Consider the case of an EPUB that contains XHTML files that link to
CSS stylesheets. We have implemented a CSS parser in XSLT2. In order
to make it work without too many annoying workarounds, we have to
unpack the zip file first.

We found it convenient to write a URIResolver that pulls content out of
zip files; that way we can process all the epub pieces in place without
the need for temporary files. It didn't present great difficulties,
although I may be missing something - we handled the spine and the rest,
but don't have a CSS parser - that sounds neat! But some ability to
enumerate the contents of the zip, (or to pull out the contents of a
"folder" from the zip - a kind of artificial construct) is a big help.



Sounds really neat. Have you published the resolver somewhere? For our
purposes, it would have to co-operate with a catalog resolver.

FYI, the CSS parser is here:
https://github.com/gimsieke/epubcheck-xproc/blob/master/xproc/css.xpl
and of course in the XSLT files used therein, namely
https://github.com/gimsieke/epubcheck-xproc/blob/master/xsl/css-parser.xsl
https://github.com/gimsieke/epubcheck-xproc/blob/master/xsl/css2xsl.xsl
https://github.com/gimsieke/epubcheck-xproc/blob/master/xsl/css-util.xsl

It is a threee-step process:
1. For a given XHTML document, extract CSS info from linked stylesheets,
inline style elements, and style attributes. Memorize priorities for every
rule.
2. Generate an XSLT stylesheet out of this CSS info. The CSS priorities
translate to template priorities.
3. Apply the generated XSLT stylesheet to the original XHTML file in order
to make every CSS property on each element explicit as an @css:* attribute.

That is, all CSS style and class attributes will be expanded to XML
attributes in the http://www.w3.org/1996/css namespace, e.g. <p
css:margin-top="2em" css:color="red" css:font-family="Arial, sans-serif"
class="foo"> so that you can use them for grouping, in Schematron rules, …

Although the epubcheck-xproc project is still quite immature, the CSS
parser and the mechanism to patch Schematron findings back into the HTML
files (step epub:schematron-spinehtml in the
https://github.com/gimsieke/epubcheck-xproc/blob/master/xproc/epub.xpllibrary)
is already quite usable.

Gerrit