Kelly,
OK! I like that element name and description better!
Thanks, DW
kelly.ray@us.pwc.com wrote:
Not sure if you received my comments
as my email bounced back from the cc attempt to ebxml-bp. But my
comments tie-in with your suggestion on a linkage out to a
"LegalRequirementsURL"
which could reference to a contractual URL or a legislative/regulatory
URL.
Thanks,
Kelly D. Ray
Director
Advisory Services
PricewaterhouseCoopers
(home office) 972-881-2420
(voicemail/fax) 214-853-4264
(cell) 972-896-5834
kelly.ray@us.pwc.com
----- Forwarded by
Kelly
D Ray/US/ABAS/PwC on 08/30/2004 12:25 PM -----
| Kelly D
Ray/US/ABAS/PwC
08/25/2004 02:07 PM
Local: 214-853-4264
Intl: 214-853-4264
Dallas
US
|
|
I had a great email response to this
that was lost as a draft. So, I'm going to try to recreate it.
I am new to standards and am just
coming
up to speed on the work of ebXML (ISO 15000) and e-Contracts, but am
active
on the LegalXML-Legislative TC.
"IsLegallyBinding" comes across
as a misnomer to me because its based on a judgment and series of
facts.
We would be somewhat socially irresponsible if we were to give people
a choice of making a commitment or representation and then indicating
that
it is not legally binding.
The answer to the question of
whether
a term is legally binding depends on the nature of the source of the
obligation
as part of the business transaction. Two sources of legal obligation
are: a) contractual terms; and b) regulatory or legislative directives.
Contractual Terms:
From the perspective of an intent to
bind and enforceability, prudence suggests only having a concern about
it, if the obligation is in fact a commitment or representation and
whether
it was made by someone with actual or apparent authority. Here are
some thoughts about these two elements as far as what might be used as
triggers:
1) "HasAuthority" - which
could be determined based upon:
a)
"title" of the person executing the transaction
b)
"RepresentedAuthority" - person has assertd that he/she has authority
to bind the organization (perhaps through a certified digital signature
validated by the organization)
2) Standard of enforceablity based
on
the Nature of the term within the contract (which falls into at least
four
areas):
a)
"commitment" - (affirmative, negative) - standard for enforceability
is a failure to comply with the commitment prior to any failure by the
other party
b)
"representation" - standard for liability is either i) knowingly
false when asserted; ii) failed to exercise due care as to veracity
c)
"contextual information" - no consequence for inaccuracy
d)
"jurisidictional" - not triggered until after a commitment or
representation trigger suggests a claim or liability
Compliance - Laws and
Regulations:
From the perspective of whether an
element
of a transaction is legally binding in the context of Compliance, I
would
encourage you to consider having an element of the business
rules/business
process schema include both a characteristic of the obligation and a
consequence
for single non-compliance and pattern of non-compliance to drive risk
management
decisions and project/process prioritization. Compliance obligations
can fall along the following spectrum:
1) Mandate - either a prescribe
action,
a prohibition, or a status that is externally imposed upon an entity
2) Commitment - for contractual
obligations,
representations to the public like we will honor a claim for X days (in
essence an oral contract)
3) Assertion - for example, we are
ISO
15000 compliant (its a voluntary position in which stakeholders may
place
value but its not a commitment)
4) Objective - for externally
communicated
targets, principles and goals where people may rely on them and thus
have
a publicity/reputational impact but not a strict legal impact
Whether to execute one transaction
over
another is going to depend on the consequences of non-compliance to the
terms. There is certainly room for improvement here, but I think
of consequences as varying between:
a) single event consequence
b) pattern of action consequence
I would characterize consequences of
non-compliance as following along the following spectrum:
a) individual criminal exposure
b) corporate criminal exposure
c) loss of licensure/permit/status
d) civil exposure - punitive
e) civil exposure - consequential
f) civil exposure - actual
g) mandated action - recall
h) mandated action - remediation
i) reputational exposure (which
would
be measured in loss of business)
The LegalXML-Legislative TC has
scheduled
a Face-to-Face for September 7th in Vermont. One segment of that
meeting is to include a discussion of interaction between
LegalXML-Legislative
and ebXML. I would encourage attendance as a specific use case that
could be built out that intersects ebXML and LegalXML-Legislative is
the
transaction of a corporation subscribing to and receiving legislative
or
regulatory content. That subscription process would require a showcase
of the intersection between the content, the transmission protocol, and
the transaction or "subscription" profile.
You can get more information about
the
Face-to-Face here:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legalxml-legislative
Hope this doesn't add more confusion
to the issue since I don't have the full context, but I have put quite
a bit of thought into how corporations must be prepared to address
"compliance"
obligations and what is required of a taxonomy to drive internal
compliance
processes, risk decisions, etc.
Thanks,
Kelly D. Ray
Attention to the LegalXML Group:
John Messing graciously provided some input to questions we had sent
recently, via a message to Sally St. Amand from the ebXML Business
Process TC. As indicated, we are soliciting any feedback from the
LegalXML group on an attribute, isLegallyBinding [1], that is
associated
with business transaction activities.
Should you have any further insight it would be most appreciated.
Thank
you ahead of time from the ebBP team.
Note: A more detailed summary if required can be found at:
http://www.oasis-open.org/archives/ebxml-bp/200407/msg00133.html.
[1] Likely to be changed to HasLegalIntent.
> Date: Mon, 16 Aug 2004 04:04:23 -0700 (PDT)
> From: "Sally St. Amand"
> To: ebxml-bp@lists.oasis-open.org
> CC: John Messing , legalxml-ms@lists.oasis-open.org
> Subject: [ebxml-bp] Input Re WI-71 isLegallyBinding
>
> Hi all
> I recently asked John Messing, an active member of the
LegalXML
> section, for an opinion on the issues we have been discussing
in
> conjunction with how to support
> international eCommerce and enforceability, and specifically
the
> isLegallyBinding
> attribute.
>
> I did my best to summarize our discussions, which Monica
has well
> documented in her emails of July 28 and July 14.
>
> John was kind enough to provide his opinion and was
supportive of
> soliciting input from other members of the LegalXML
section. To
> that end I have copied them and would ask for their
input. John's
> response is below. We appreciate the assistance on an
issue I
> believe is important to both groups albeit from different
> perspectives.
>
> Sally
>
> */John Messing <jmessing@law-on-line.com>/* wrote:
>
> Thank you for the opportunity of reviewing
this question. The
> following
> is my own opinion, with which others may
agree or disagree.
>
> > Most of our TC's discussion on this
issue has been whether
> isLegallyBinding
> > inferred test or production capabilities,
the purpose of the
> > attribute (and potential impact on
technology), whether the
> name should be changed to something else,
eg
> isLegallyEnforceable or isLegallyIntent,and
whether we should
> change it from an attribute to an element
on the assumption
> that there is additional complexity that
will need to be
> addressed in future versions.
>
> 1. Inference of special test or production
capabilities.
>
> I do not believe this parameter requires
any special
> capabilities apart
> from that given to any other element or
attribute that is
> tested to
> determine if the proposed standard works
satisfactorily! in an
> interoperability environment (e.g., whether
the XML is valid,
> well-formed, and capable of being written
and read
> satisfactorily by
> applications).
>
> 2. Purpose and potential impact.
>
> I think the purpose of the parameter is
to document along with
> other
> pieces of information whether the party
who invokes the parameter
> intends to be bound legally to a representation
or promise so
> as to
> induce action in reliance by another party,
who may later need
> to seek
> legal
> enforcement. Legal and moral commitments
apply to
> people and through them to the entities
on whose behalf they act.
> To my way of thinking they involve moral
criteria, which
> differ from
> real world and virtual criteria as much
as the latter may
> differ from
> each other. One bind's human identities
to cryptographic keys
> through
> certificates based upon procedures by
which humans introduce other
> humans to a computing network for purposes
of registration, as a
> matter of techology. Similarly, one binds
humans and the
> entities for
> whom they act to promises and statements
upon which others rely,
> through the mechanism of construed legal
intent. The
> IsLegallyBinding parameter can help to
document whether such
> intent existed at the time the transaction
was concluded.
>
> Probably the existence of the IsLegallyBinding
parameter will
> not be
> determinative but will be one important
piece of information to be
> assessed by a decision-maker overall in
trying to determine
> the intent
> of a promisor in the context of a legal
dispute. Other
> information at
> the application level about how the parameter
is triggered for
> inclusion will probably be needed as well,
including the GUI
> that the
> user experienced, to allow drawing a conclusion
that what the user
> activated
> was what the user intended, and what was
intended was correctly
> recorded and transmitted by the application.
It is not terribly
> different from constructing! a secure
audit trail, though the
> purposes
> and conclusions may be significantly different.
>
> 3. Changes
>
> I do not think its name should be changed
so long as the
> definition is
> clear. Nor do I necessarily think that
it needs to be an
> attribute,
> although obviously if there are some parameters
in a
> transaction that
> are intended as legally binding and others
that are not, then
> attribute
> status may be prefereable to distinguish
between them. This
> probably can
> best be determined in the context of use
cases, and I cannot
> tell as a
> general principle which is better.
>
> I hope this is useful. Please forgive
the disclaimer that
> follows, but
> my training tells me it is prudent under
the circumstances.
> This email
> and its contents are not legal advice,
there is no right to
> rely upon
> the statements for a specific legal purpose,
no attorney client
> relationship is created, and no electronic
signature should be
> inferred
> or implied.
>
> Best regards.
>
To unsubscribe from this mailing list (and be removed from the roster
of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/leave_workgroup.php.
_________________________________________________________________
The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer.
|