[no subject]

>    - TransformedDocuments (any of the post-transformed documents)
>    - UntransformedDocuments (any of the pre-transformed documents)
>
>So basically, when specifying each "DocumentSelector", the client says 
>envelope/don't envelope.  Then the client says where the resulting 

>signature is "placed".  This determines everything wrt 
>enveloped/enveloping/detached.
>

<JC>No, again, it does not say everything wrt because it does
not say where to envelope the signature in the enveloping document, and
this is the reason for my proposal </JC>

>Then as a separate aspect, the client asks for outputs - and he can ask for 
>any combination of outputs he wants, each output is just a different "view" 
>into the processing that was performed by the server.

<JC>Look to it in another way: using the approach I propose, in the
ToBeDefinedElement
you define THE MAIN OUTPUT corresponding to the request:ie, how the
ds:Signature will
be delivered to the requester, and in the OutputOptions you indicate
additional things the
requester wants to get: transformed documents, and so on....
I think that this is also a coherent view...
</JC>
>
>What I've left unspecified is how to specify "SignaturePlacement".  That 
>is, how to point to a place in an XML document and say "stick the signature 
>here".  In your schema, you do this with:
>
><xs:element name="AfterElement" type="ds:TransformsType" />
>

<JC>
As I said, the XPath defines a language allowing you to identify a certain
element
within one document using not very dificult expressions. If you want more
details
I could give you some examples..but now I am in a bit hurry...From this
point of view,
by identifying an element within a document the server could conclude, OK,
this is he
element after whose end I have to insert the ds:Signature.
Now, a potential problem: I have been working with some XPath processor,
but I am not
an expert. What I know is that given an expression, these processors return
the contents
of the element identified, but do not give you a hook to the place where
this element is
in the document ....which puts some programming problems on the table,
unless we
use two transformations in the SignaturePlacementTYpe: the first one returning
the part of the XML document that comes BEFORE the ds:Signature and the
second one
returning the part of the XML enveloping document that will come AFTER the
ds:Signature
once it i will have been inserted!.
Once again, this is somethign that I say before looking more closely to the
features of the
XPath processors....
</JC>

>Could you explain how this works?
>
>
>>         I propose then to add the element EnvelopingDoc (and we can discuss
>>afterwards
>>         how to indicate where to envelop the signature within one 
>> document), within
>>         an optional choice that contains both, EnvelopeThisDocument and
>>Enveloping. If none of them
>>         appears, then the server asumes that the requester wants it
detached.
>




>I don't like this - the signature can envelope lots of docs, but it can 
>only by enveloped once, right?  So we shouldn't tempt people to specify 
>"EnvelopeThisDocument" on different DocumentSelectors.  In any case, I 
>think the questions:
>  - what does the signature contain
>  - where is the signature placed
>
>are best viewed separately, not smushed together.
>

<JC>
Again we are in disagreement, please take a moment to think about
the reasons I have given to you on the basis of the schema I proposed.

</JC>
>
>>         4. I propose to make EnvelopeThisDocument an empty element. Its 
>> presence
>>indicates
>>         that. Its absence clearly indicates that it will not envelope the 
>> signature.
>>
>>         5. WhichInputDocument. Could it be an attribute? It is an integer 
>> pointing to
>>         the document passed to the server...this would make it shorter. 
>> And we do not
>>         expect it will be required a structure for doing that...
>>
>>         6. I propose to change the name of ds:Transforms element to
>>"RequestedTransforms",
>>         that would be of type ds:TransformsType, because it indicates 
>> that these
>>         are transforms that the sender requests the server to perform (in 
>> the sign
>>request
>>         there can be indications of already performed transforms done by
the
>>sender and
>>         it is good to differentiate them).
>>
>>         7. I propose to put this information WITHIN the root child that 
>> contains the
>>         documents sent to the server (your InputDocuments element). This
>>         element would have two children:
>>                 - SubmittedDocuments
>>                 -DocumentManipulations (or whatever name we select).
>
>The rationale for putting InputDocuments at the end was that these 
>documents could be large, so if they come after everything else, then it 
>would be easier to visually inspect protocol messages.  So I would at least 
>reverse the order of those elements.

<JC>
I understand the reason for puting InputDocuments at the end...Yes,
I think that proposal 7. is not a big issue.... let us concentrate on 
my comments on how to manage the enveloped/enveloping issue...
</JC>
>
>Trevor 
>