Re: C14N remark

Toman_Vojtech@emc.com writes:

>>From the meeting minutes October 2:
>
>>   ... On C14N, we've already discussed this and said it was a
> user-defined
>>   option on serialization.
>>
>>   Norm: Good point! Thank you, Mohamed.
>
> True, but do we mention this in the spec somewhere? (Perhaps we don't
> have to...)

We probably should provide an optional p:c14n serialization method
that does C14N. At least that way, implementors won't have to invent
their own.

Or is that not the right way to trigger it?

> It just occurred to me that having C14N as an option on p:serialization
> can make using C14N in XProc quite tedious. Because it is on the
> p:serialization level, you can do C14N only in environments where you
> actually *serialize* the outputs (p:store or when you run a pipeline in
> a shell, for instance).

But C14N is defined to produce a sequence of characters. I don't think
it's meaningful to speak of a C14N infoset.

> But if you want to do C14N in step A and then
> pass its (canonicalized) output to step B, you are in trouble. You will
> have to run step A, store its result (with C14N turned on) to an
> external location, and let step B read the data from there. Not very
> nice nor reliable, I think.

Doesn't

  <p:wrap wrapper="c14n-content" match="/*"/>
  <p:escape-markup method="p:c14n"/>

do what you want? That will return a <c14n-content> document that
contains a single text node which is the C14N'd characters.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | All the labors of the ages, all the
http://nwalsh.com/            | devotion, all the inspiration, all the
                              | noonday brightness of human genius, are
                              | destined to extinction.--Bertrand
                              | Russell