Accepting serial as the QName of a named <xsl:output>

4 views
Skip to first unread message

max toro q

unread,
Dec 17, 2009, 7:05:55 PM12/17/09
to exp...@googlegroups.com
Florent,
I was going to ask you the same thing, I'm glad your are making
boundary optional.

I want to tell you about a feature that's hard to implement: Accepting
serial as the QName of a named <xsl:output> element. The processor I'm
targeting (Microsoft .NET) does not expose the XSLT DOM or any other
implementation details, so I cannot get a reference to the
<xsl:output> node. Even if I did, I wouldn't have access to it when
the extension function is called. This could be an issue also with
other closed-source processors.

Personally, I don't like the fact of having features that are
available only for a particular host language, XSLT in the case.

On the other hand, accepting serial as element(xsl:output) is do-able.

Anyways, I'm not saying you should drop it, just wanted to express my concerns.
--
Max

2009/12/17 Florent Georges <fgeo...@gmail.com>:
> 2009/12/17 Markus Pilman wrote:
>
>> I have a comment on the multipart-part of the specification
>> with in the http-client.  The spec sais, that in http:multipart
>> the boundary attribute must be set.  I think it would make
>> sense to make the boundary attribute optional and let the
>> implementation chose one if the user does not specify one for
>> the following reasons:
>
>> - for convenience it would be good if users wouldn't have to
>> bother about boundaries
>
>  Yes, I agree.  Actually I eventually based the function on the
> corresponding XProc step.  And boundary is required there.  I
> must admit I found that quite annoying, but I kept it.  Maybe
> this was not the best choice (I don't like neither the error if
> the boundary starts with '--' in XProc).
>
>> - if the user sends binary data he cannot chose a boundary
>> wisely (or it would be difficult) without the chance to find
>> the boundary in the data.  An implementation could if it knows
>> the whole content in the begin.
>
>  I guess, yes.  I am not sure current implementation actually
> look at the content to ensure the boundary is not there, instead
> of just using a clever obfuscation based on current time and
> other random stuff.
>
>  But at least, most of the boundaries used over there are
> generated by softwares (mostly browsers) without any help of the
> users.  So at least that's the way it works for now.
>
>> - There is at least one http client implementation (libcurl)
>> which does not allow the user to set the boundary manually
>> (because libcurl does not support it, probably a lot of
>> implementators will run into this problem).
>
>  So you are using libcurl? ;-)
>
>> I am aware that the third reason is not that kind of a good
>> reason :-)
>
>  Or maybe it is.  The objective of EXPath is to define
> interoperable extensions, but also their limits, investigating
> what's possible, or what's useful and what's not, based on
> experience.  Implementation details can be part of that process
> (what's the point to define an extension that is not
> implementable with one of the leading library existing out
> there?)
>
>  I'll change the boundary to be optional.  Thanks!
>
>  Regards,
>
> --
> Florent Georges
> http://www.fgeorges.org/
>
> --
>
> You received this message because you are subscribed to the Google Groups "EXPath" group.
> To post to this group, send email to exp...@googlegroups.com.
> To unsubscribe from this group, send email to expath+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/expath?hl=en.
>
>
>

Florent Georges

unread,
Dec 18, 2009, 6:07:14 AM12/18/09
to exp...@googlegroups.com
2009/12/18 max toro q wrote:

Hi,

> I was going to ask you the same thing, I'm glad your are making
> boundary optional.

Good, seems to be the right thing :-)

> I want to tell you about a feature that's hard to implement:
> Accepting serial as the QName of a named <xsl:output> element.
> The processor I'm targeting (Microsoft .NET) does not expose
> the XSLT DOM or any other implementation details, so I cannot
> get a reference to the <xsl:output> node. Even if I did, I
> wouldn't have access to it when the extension function is
> called. This could be an issue also with other closed-source
> processors.

First, I must admit I want to change the serialization stuff in
the HTTP Client, as it is under-specified and not very consistent
as for now. Especially when related to multipart. I'll send a
separate email as soon as possible on that subject, as it seems
several people are implementing it, so I can't wait any longer...

About the QName, actally that's not the name of an xsl:output
element, but the name of an output definition. That's slightly
different. The most important point here is that it represent an
abstract set of serialization parameters, not an element node.

So your processor does not have to give you a way to navigate
the source XML nodes of your stylesheet (what I do not expect a
processor to provide), but instead to give you access to the
serialization parameters of an output definition (what I do
expect processors to provide).

Well, at least that's for XSLT 2.0. The concept was the same
in XSLT 1.0 excepted there was only one output definition: the
default one (with no name). So basically in XSLT 1.0, you can
just access serialization parameters, not regrouped by name, as
they are always global to the whole transform.

> Personally, I don't like the fact of having features that are
> available only for a particular host language, XSLT in the
> case.

Yes and no :-) Of course the impact of a single technology
should be minimized as much as possible, but on the other hand, I
do not want to reinvent the wheel for something as complex as the
serialization paramaters, which have been already specified in
their own REC at W3C. XSLT has a consistent way to represent
them, so I think this is sensible to reuse it.

That said, we could find a more clever way to do so. I guess
it would be ok to say this is the name of an output definition
(defining an output definition as a named set of serialization
parameters as defined in the related REC). And that the way to
create an output definition is host-language-dependent. And that
in the case of XSLT 2.0 that corresponds to an XSLT 2.0 output
definition, in XQuery that corresponds to the implementation-
defined way of setting the serialization parameters, etc. And a
reference to an unknown output definition is an error.

So an XSLT 1.0 implementation could provide no way to define
new output definitions (as the language itself does not support
them). So any attempt to reference a named output definition
would result in an error.

> On the other hand, accepting serial as element(xsl:output) is
> do-able.

Yes. I know that can be quite surprising to see xsl:* here,
but that's a REC that defines an XML representation of the
serialization parameters defined in "XSLT 2.0 and XQuery 1.0
Serialization", and as far as I know, that's the only one.

> Anyways, I'm not saying you should drop it, just wanted to
> express my concerns.

Thanks about that. Implementors feedback is very important for
EXPath. Especially about issue implementing something that's
been defined or that is being defining.

Oh yes, and that's a very good news to know someone implements
the HTTP Client for the .NET processor. I was not aware of that,
thank you and good luck!

Philip Fearon

unread,
Dec 18, 2009, 6:47:17 AM12/18/09
to exp...@googlegroups.com, maxt...@gmail.com
@max toro q

You may already be aware of this (I only stumbled across it recently),
but there is actually a way of getting the xsl:output details (not the
node itself) from the .NET XSLT processor, using:

XslCompiledTransform..::.OutputSettings Property

(From Microsoft documentation) "Gets an XmlWriterSettings object that
contains the output information derived from the xsl:output element of
the style sheet."

Phil Fearon

On Fri, Dec 18, 2009 at 12:05 AM, max toro q <maxt...@gmail.com> wrote:
> Florent,
> I was going to ask you the same thing, I'm glad your are making
> boundary optional.
>

max toro q

unread,
Dec 18, 2009, 11:20:05 AM12/18/09
to Philip Fearon, exp...@googlegroups.com
Thanks for the help. I was aware of that property.

As Florent pointed out:

> So an XSLT 1.0 implementation could provide no way to define
> new output definitions (as the language itself does not support
> them). So any attempt to reference a named output definition
> would result in an error.

... so I should just throw an error.

Anyways, I'm curious about the implementation on processors that do
support mutiple output definitions. When the extension function is
called (C#, Java or whatever), how do you get a reference to the
object that has that information ?
--
Max

2009/12/18 Philip Fearon <pgf...@googlemail.com>:

Florent Georges

unread,
Dec 18, 2009, 12:17:11 PM12/18/09
to exp...@googlegroups.com
2009/12/18 max toro q wrote:

>> So an XSLT 1.0 implementation could provide no way to define
>> new output definitions (as the language itself does not support
>> them).  So any attempt to reference a named output definition
>> would result in an error.

> ... so I should just throw an error.

Yep, I think so.

> Anyways, I'm curious about the implementation on processors that do
> support mutiple output definitions. When the extension function is
> called (C#, Java or whatever), how do you get a reference to the
> object that has that information ?

Good question ;-)

For instance with the new API from Saxon (aka s9api), the
compiled stylesheet is an XsltExecutable, from which you can get
the underlying PreparedStylesheet (the compiled stylesheet in the
original API), from which you can get an Executable, from which
you can get a Java Properties object (basically a dictionnary
that maps keys to values) by using:

getOutputProperties(StructuredQName qname)

(the qname is the name of the output definition). The following
complete example:

public class NamedOutputDefinition
{
public static void main(String[] args)
throws SaxonApiException
{
Processor proc = new Processor(false);
XsltCompiler compiler = proc.newXsltCompiler();
Source style = new StreamSource(STYLE_PATH);
XsltExecutable exec = compiler.compile(style);
Properties out_def = exec
.getUnderlyingCompiledStylesheet()
.getExecutable()
.getOutputProperties(OUT_NAME);
if ( out_def != null ) {
out_def.list(System.out);
}
}

private static final String STYLE_PATH = ".../my.xsl";
private static final StructuredQName OUT_NAME =
new StructuredQName("", "", "max");
}

will output the following if my.xsl has a named output definition
named "max" with just the @method set to "text":

-- listing properties --
method=text

Well, actually, Saxon does retain those properties untill
stylesheet runtime only if one xsl:result-document does have a
@format computed at runtime (if not, it can get the properties as
needed at compile time). For instance the following is a minimal
example of such a stylesheet:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="2.0">

<xsl:output name="max" method="text"/>

<xsl:template name="main">
<xsl:result-document format="{ something }"/>
</xsl:template>

</xsl:stylesheet>

I guess that when using the Saxon's new integrated extension
functions, we should have the opportunity to behave as an
xsl:result-document: either access the properties at compile-time
or ask to retain them until runtime. But that's just guessing...

Florent Georges

unread,
Dec 18, 2009, 12:45:22 PM12/18/09
to exp...@googlegroups.com
2009/12/18 Florent Georges wrote:

>  I guess that when using the Saxon's new integrated extension
> functions, we should have the opportunity to behave as an
> xsl:result-document: either access the properties at compile-time
> or ask to retain them until runtime.  But that's just guessing...

For the records, I can see how to achieve that with an
extension instruction (by getting the stylesheet object with
StyleElement.getPrincipalStylesheet(), then calling
setNeedsDynamicOutputProperties(true)) but not for an extension
function (that is, an ExtensionFunctionCall object).

That's interesting because this is the typical example of
issues one can find while implementing an extension function
"from the outside" of the processor, while I guess it could be
done easily with control over the processor code (implemented
"from the inside").

max toro q

unread,
Dec 18, 2009, 1:00:46 PM12/18/09
to exp...@googlegroups.com
This means you haven't implemented "Accepting serial as the QName of a
named output definition" ?

The ExtensionFunctionCall object is only given the function arguments,
no stylesheet properties.
--
Max

2009/12/18 Florent Georges <fgeo...@gmail.com>:

Florent Georges

unread,
Dec 18, 2009, 1:49:59 PM12/18/09
to exp...@googlegroups.com
2009/12/18 max toro q wrote:

> This means you haven't implemented "Accepting serial as the QName of a
> named output definition" ?

Yes, not yet ;-)

> The ExtensionFunctionCall object is only given the function arguments,
> no stylesheet properties.

And the static context. While the output definitions are not part
of the static context, it could have been a good place to either get
them or get another path to a Saxon object with that info.

Michael Kay

unread,
Dec 18, 2009, 1:55:57 PM12/18/09
to exp...@googlegroups.com
>
> The ExtensionFunctionCall object is only given the function
> arguments, no stylesheet properties.

Saxon supplies the function arguments at the time of the call (at run-time),
but you can supply anything you like at the time the ExtensionFunctionCall
is instantiated (which will be at stylesheet compile time).

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay

max toro q

unread,
Dec 18, 2009, 8:42:14 PM12/18/09
to exp...@googlegroups.com
Yes, but the ExtensionFunctionDefinition object is registered at the
Processor level, so any stylesheet information that I pass to
ExtensionFunctionDefinition so it can pass it to the
ExtensionFunctionCall would be valid only for the first stylesheet,
and not for other stylesheets that share the same processor, am I
right?
--
Max

2009/12/18 Michael Kay <mi...@saxonica.com>:

Michael Kay

unread,
Dec 19, 2009, 5:29:27 AM12/19/09
to exp...@googlegroups.com
Sorry, I explained this wrong.

Yes, the ExtensionFunctionDefinition is effectively immutable, it only holds
information about the extension function itself. But it is called at compile
time to instantiate the ExtensionFunctionCall, and the ExtensionFunctionCall
is then called at compile-time (supplyStaticContext() method) which allows
it to save any information it needs from the static context (for example,
collations or namespace bindings) which it can then use when it is called at
run-time (the call() method).

Regards,

Florent Georges

unread,
Dec 20, 2009, 9:02:40 PM12/20/09
to exp...@googlegroups.com
2009/12/19 Michael Kay wrote:

> Yes, the ExtensionFunctionDefinition is effectively
> immutable, it only holds information about the extension
> function itself. But it is called at compile time to
> instantiate the ExtensionFunctionCall, and the
> ExtensionFunctionCall is then called at compile-time
> (supplyStaticContext() method) which allows it to save any
> information it needs from the static context (for example,
> collations or namespace bindings) which it can then use
> when it is called at run-time (the call() method).

Thanks, Michael. However, I think in this case (getting
access to the output definitions) we have to access the
XSLStylesheet object at compile-time, but I cannot think of
a way to pass this object to the function call object.

The function definition object is instantiated outside the
scope of a particular stylesheet, it is not called by Saxon
with the stylesheet object, and the function call object is
called with the static context, but it later does not
provide the output definitions, directly or indirectly.

Is there any way to access output definition properties
from an extension function?

Michael Kay

unread,
Dec 21, 2009, 5:20:52 AM12/21/09
to exp...@googlegroups.com
It seems that named output definitions are available in the Executable
object (reachable from the static context) only if there is at least one
xsl:result-document instruction with a dynamically-computed format
attribute.

Rather than relying on named output definitions, you might be better off
mimicking the fn:serialize() function defined in
http://www.w3.org/TR/xpath-functions-11/#func-serialize

Regards,

> -----Original Message-----
> From: exp...@googlegroups.com
> [mailto:exp...@googlegroups.com] On Behalf Of Florent Georges
> Sent: 21 December 2009 02:03
> To: exp...@googlegroups.com
> Subject: Re: [expath] Accepting serial as the QName of a
> named <xsl:output>
>

Florent Georges

unread,
Dec 21, 2009, 6:52:49 AM12/21/09
to exp...@googlegroups.com
2009/12/21 Michael Kay wrote:

> Rather than relying on named output definitions, you might be
> better off mimicking the fn:serialize() function defined in
> http://www.w3.org/TR/xpath-functions-11/#func-serialize

Mmh, yes, seems a good idea. That's actually more or less the
same I ended up with baed on xsl:result-document, except that
this one does not support character maps (I think this is not
essential in the HTTP Client neither) and the named output
definitions.

That was a nice way to factorize out same sets of output
properties, but this is maybe dangerous to rely on information
that is not part of neither the static nor the dynamic contexts
for an extension function which is maybe implemented outside of
the processor internals (as showed in this thread). And because
we use element nodes (and not instructions), we can always
factorize out the way we construct them at runtime instead.

And I can certainly see the advantage of being consistent with
fn:serialize() :-)

Thanks for the idea!

Florent Georges

unread,
Jan 9, 2010, 12:25:24 AM1/9/10
to exp...@googlegroups.com
2009/12/18 max toro q wrote:

Max,

> I want to tell you about a feature that's hard to implement:
> Accepting serial as the QName of a named <xsl:output>
> element. The processor I'm targeting (Microsoft .NET) does not
> expose the XSLT DOM or any other implementation details, so I
> cannot get a reference to the <xsl:output> node.

The new revision of the spec that has just been release
<http://www.expath.org/modules/http-client.html> should resolve
this, as it changes the way serialization is handled. Could you
confirm this is ok for you?

Reply all
Reply to author
Forward
0 new messages