Re: [legalxml-enotary] FW: LegalXML eNotary Update

[Arshad Noor <arshad.noor@strongauth.com>]

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.

Thanks.

Arshad

----- Original Message -----
<snip>

From: Lira, Abdias [mailto: Abdias.Lira@wolterskluwer.com ] 
Sent: Tuesday, April 29, 2008 10:28 AM 
To: Mark Ladd 
Cc: HGardner@mortgagebankers.org 
Subject: RE: LegalXML eNotary Update 

Mark, 

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. 

Thanks. 

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 
abdias.lira@wolterskluwer.com 
www.WoltersKluwerFS.com