|Subject:||Re: [legalxml-enotary] FW: LegalXML eNotary Update|
|From:||Arshad Noor (arsh...@strongauth.com)|
|Date:||May 7, 2008 10:12:24 am|
I need to respond to all the comments I've received so far, but a deadline on a project next week is consuming my attention right now. After May 15th, I have set aside many weeks to devote to OASIS-related work - both LegalXML and EKMI - so I will catch up with all comments within 2 weeks.
However, I would like to comment on Abdias' comments right now, since they are few and easier to address immediately:
1) I agree with John Messing that a graphic representation of elements/objects from the XSD should not be within the scope of the XSD itself. It can, however, be a separate undertaking if the TC wants to do (which may not be such a bad idea in itself given that there are no standards in the GUI industry for many business-issue related artifacts);
2) Abdias is correct that the notary signature is always expected to be in the "notarial" certificate (not digital certificate). We have to standardize on some things while ensuring that we are fair to all vendors and users in the marketplace. I realize that Adobe has its own way of capturing document signatures in its schema, and the eNotary TC's XSD does not match what Adobe has currently.
However, if we were to bend our XSD to accommodate Adobe, then we run into the problem that we will hear from Microsoft, IBM, Sun and every other vendor on the planet who has an interest in electronic signatures in documents.
My TC-member position is: better to let ALL vendors adjust a little bit to an industry standard (which is fair to all, IMO) than for an industry body like OASIS to adjust to a few vendors. However, as a TC consultant, the TC drives my deliverable - so I'll let the TC dictate what needs to be done here.
3) I'm not sure if Abdias understood that the staturory language of the notarial act is embedded in the notarial certificate - and this element does not mandate any specific language but allows application developers to put in whatever statutory language they need for the certificate. So, perhaps, this may need to be clarified in the next rev of the PDF; it will definitely be clear in the specification and examples that we provide before the end of this year.
----- Original Message ----- <snip>
This looks better than the previous proposal. For SMART DocÂ®, we could use what they are calling the âe-notary elementâ alternative.
Here are some comments:
1. The proposed structure is invisible to the end-users. There seems to be no provision for how to display the certificate on the body of the document or how to link the proposed e-notary structures with the appearance of the certificate and notary signature in the body of the document.
2. If I understand this correctly, it seems that they are making the assumption that the notary signature is always going to be embedded in the certificate structure. Some document formats, like PDF, have their own signature objects. There should be a way to link the certificate to a signature object in the document for the notaryâs signature. In sdv3 we are doing that in a indirect way by having the NOTARY_SIGNATURE_FIELD definition point to both the signature field as well as to the certificate field.
3. There is no provision on how to merge the notarial act data with the statutory language. I understand that the language does not stand by itself. It is either a template or it filled out. If it is filled out, then there should be a way to identify the locations of the various fields in it. We talked about this in one of our recent sdv3 meetings.
Abdias Lira Principal Software Architect Software Product Development Wolters Kluwer Financial Services 3468 Archgate Court Alpharetta, GA 30004 770-442-0985 office 586.764.4710 mobile abdi...@wolterskluwer.com www.WoltersKluwerFS.com