OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: Visual Signature Profile - second working draft

Hello Ezer,

thanks for you mail ...

Ezer Farhi schrieb:
> [...] remark about not having conflicts with PDF and OOXML, I listed
> this remark internally for us as so we will have some guidelines for
> the profile. I agree that this remark should be removed either now
> or just before submission of the profile.

A lot of remarks for one sentence ;-)

Nevertheless, I think we are now in agreement and we could remove the

> Remark: It is mandatory that the proposed profile will not impose any
> conflict with existing document standards such as PDF or OOXML, so 
> that it is possible to use the profile for incorporating visual 
> signatures into these documents types

Maybe using Word's comment features or making the background yellow,
would help in the future to clearly distinguish which parts of the
document are "internally for us as ... guidelines " and what not.

A daft proposal for discussion, on what "internal guideline" for the
visual signatures profile could look like from my perspective, follows:

The proposed profile shall in its first sections abstractly deal with
visual signatures and it shall be agnostic of the document format.
Therefore potentially imposing requirements and specifying normative
language, not compatible with certain document types (e.g. XML, XHTML,
PDF, OOXML, RTF, Plaintext, ...).

We will however try to avoid incompatibilities. Especially, where
certain document types offer sufficiently clear functionality to solve
certain requirements (to be decided on the TC's discretion); we shall
consider these functionalities when defining the elements and structures
for optional inputs and outputs.

Hence the avoidance of conflicts with existing document standards is of
high importance, but not a paramount necessity.

Where the requirements indicate a need or where certain document types
do not offer sufficiently clear functionality, we shall try to exploit
extension mechanisms and clearly specify the use, syntax and semantics
of elements added to the document types.

This leads us to what later sections of the profile may look like.

Given that the first sections of this profile shall abstractly deal with
visual signatures and hence be agnostic of the document format, later
section shall provide concrete solutions for concrete document types.

Here we even have the chance to specify multiple solutions for one
document type and clearly state the strengths and weaknesses of the
certain document types to meet our requirements.  Even exceptions could
be made for certain document types, if this is absolutely necessary.

We as a TC are hence free to make certain requirements optional in these
later section, if certain concrete solutions, do not offer sufficiently
clear functionality as well as they cannot be extended in a suitable manner.

We as a TC are also free to specify concrete solution of the visual
signature profile, potentially ignoring or avoiding certain requirements
just for the sake of compatibility and especially for verification. This
however will have to be stated prominently.

So it is possible to use the profile for incorporating visual signatures
into various documents types.

If for example we identify requirements that are not elegantly solvable
in PDF or OOXML we shall address those to the relevant groups taking
care of the PDF or OOXML standards.

kind regards

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]