[
Lists Home |
Date Index |
Thread Index
]
I publish it in a document type, and that might not
be HTML. So MIME types are an issue.
The document type may contain instructions for how
the contents are to be processed. These may be
instructions to the humans (usually are) but they
can be instructions to the machines the humans use
as a convenience to them. Consider a document
which includes not only XML, but an RDF section
for establishing an ontology of terms which will
control aspects of the proposal negotiation.
I don't want to negotiate the contents of each
instance at runtime. I want them to return
the Proposal to me in exactly the format and
exactly the topical content I require. Yes,
this can vary by RFP process parties, and yes,
I will send them the instructions for what is
expected in the return document, and yes, I
control that aspect of the negotiation. The
only control they have is how they analyze and
determine their response to my instructions.
It isn't quite as simple as we want it to be.
Still, this can be done as long as I have agreed
upon document types with sufficient strength in
the description to ensure fidelity. Schemas work
well for that even if only to ensure that what
is returned is syntactically well-formed and
has the element and attribute types I ask for.
len
-----Original Message-----
From: W. E. Perry [mailto:wperry@fiduciary.com]
"Bullard, Claude L (Len)" wrote:
> In the sense that I want to ensure that if I send a RequestForProposal, a
> Proposal is returned, or am able to inquire that if I
> send a RequestForProposal, I can get back an answer that says, No, or Yes in
> a few weeks, or Yes by The Deadline You Specified,
The loosely-coupled web of outcomes architecture that I am describing directly
facilitates what you desire. You create an RFP document and publish it an
appropriate location (very RESTy). Access to that document at that location is
controlled by the now well understood mechanisms of the Web (again RESTy). Each
party interested in that document satisfies the access requirements in order to
GET it, thereby establishing basic understanding of and competence with that
document type. Each of those interested parties, as an expression of its
particular expertise, will consider--that is, process--that RFP in a unique
manner which takes account of, among other things, the specific, possibly
unique, manner in what that party would deliver on the contract if it were
awarded the job. In order to achieve the most exact statement of each party's
expertise, the outcome of the RFP creation process (as later the outcome of
each process under the contract will be) should be instantiated in a form which
specifically reflects the particular expertise of the functions which created
it, rather than in some pre-agreed form which may vitiate, or distort into
ambiguity or worse, the particular semantic outcome of that party's expert
process.
The expression of that outcome, however, will be a simple syntactic body--a
document--from which, upon reviewing that document in a subsequent process, the
original requester might elaborate marginally different semantics. Such
misalignment of understandings is inevitable and inherent in human
communication. The difference here is that the parties share a concrete
document--not a schema, but an instance--through their separate further
processing of which their different understandings might be brought closer into
line. That is what a contract is: a text agreed upon where the semantics
elaborated from it will necessarily differ with each reader, given their
inherent differences of perspective and expectation. Instead of hiding the
inevitable ambiguities of any transaction between peers, where one party does
not dictate the entirety of the semantics to the other, the document
represents--in fact, is--the best statement at any moment of the agreement and
common ground accepted by the parties. This is so precisely because it is a
bare instance and not the instantiation of agreed semantics. And on that
distinction hinges the crucial difference between the monolithic and the
loosely-coupled architectures.
|
