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 
> <mailto:Philip.Fennell@marklogic.com>]
> *Verzonden**:*vrijdag 6 januari 2012 15:46
> *Aan:* Geert Josten; Jostein Austvik Jacobsen; xproc-dev@w3.org 
> <mailto: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] 
> <mailto:[mailto:geert.josten@dayon.nl]>
> *Sent:* Friday, January 06, 2012 1:34 PM
> *To:* Jostein Austvik Jacobsen; xproc-dev@w3.org <mailto: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 
> <mailto:josteinaj@gmail.com>]
> *Verzonden:* vrijdag 6 januari 2012 11:49
> *Aan:* xproc-dev@w3.org <mailto: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 
> <mailto: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.xpl 
> library) is already quite usable.
>
> Gerrit
>