Re: XFoms "suspend and resume" support

Hello Josef,

Josef Dietl wrote:

> Hello Joern and Stéphane,
> 
> I may have missed something, but there appears to be some redundancy:
> 
> 
>>through a very simple interface based on the XLink roles defined by 
>>XForms we can identify the type of requested data (container, model, 
>>instance, UI, external data-list) and the implementing 
>>(application-specific) connector classes can resolve the hrefs on 
>>instances and load the appropriate form to display/edit them.
>>
> 
> Actually, the way the XLink stuff for XForms is supposed to work is like
> a 3rd party link or external linkbase according to the XLink spec. Can
> you explain why you need the additional roles "container" and "external
> data-list"?

this is maybe just because our implementation is still experimental and 
we were forced to make some simplifications (always based on our current 
understanding) from the spec which lead to these roles.
these simplifications are:
- for us a container represents a storage entity, that means our 
application has to store the container in some way to persist the 
information about which model and instance and UI are associated for a 
specific context. it is the glue that connects the pieces. (this is 
especially interesting when some model may work with different UIs, an 
equivalent of a database-view)

- we decided to not load preset datalists (for use with selectOne/Many) through the

instance as proposed by the spec for two reasons:
- (timeline) we found it much easier to implement it through some custom 
tags in our own namespace and load the lists directly into the UI or 
model through simple XSLT extensions.
- (code complexity)  we decided to not change our instance connector 
architecture at the moment (until next refactoring) cause it's already 
quite complex ;) but to enhance the interface and support arbitrary 
datalists (which is quite flexible). we simply took the freedom to 
define some additional XLink-roles which signal our application some 
context information.


> 
> Another question: Are you building solutions combining XForms with
> Digital Signatures? - If so, did you find anything in the current design
> that precludes that combination?

not yet, but security issues play a significant role in our project and 
it's planned to support it as soon as the core processor is stable.

there MAY actually a interesting point to consider:
as far as i understand the DOMHASH workings which are the groundwork for 
  XML sigs, these allow to encrypt and sign with document-granularity. 
this is because a signature must be calculated on the basis of a whole 
document and then attached to it with an envelope to ensure integrity of 
the key.

so, if one considers one instance as a potential document where do we 
put the hash and when is it calculated?

Joern


> Josef
> 
> 
>

Received on Tuesday, 25 September 2001 15:11:43 UTC