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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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

Subject: traceability of transactions

Hello All,

Here is an issue that requires discussion.

Issue from the Information Model:

Currently the information model supports traceability of
transactions. That is, the information model requires log-type attributes
that would allow one to construct the history of the registered item's
metadata, based on the requests for creations, modifications and
deletions. We all recognize that each registry should keep track of this
information.  Should this functionality be standardized?


Len Gallagher's initial response...(with his permission)

Boy -- this is a really tricky question - subject to various
interpretations, but maybe a good one to get discussion going. The words
"standardized functionality" is what leads to various interpretations of
what should be standardized.
My own response would be -- it is not necessary to standardize the exact
entities used to model the "traceability of transactions", but it is
appropriate to standardize an interface to the Information Model, e.g. to
standardize a Query that asks "What is the log of modifications to a given
registered item?" and to standardize the response as an XML document. In
my mind, an appropriate response would be an XML document that represents a
JOIN of the entities, SUBMISSION, CONTACT, REQUEST, and IMPACT, producing
output with XML Elements something like:
Date ImpactCode ContactName ContactOrg ContactEmail
The Information Model would not have to be implemented directly; instead,
it would just be used to "define" what the output of the standardized Query
looks like. However, the Information Model would have to be standardized
as a definition in order to make this work.
Does that make sense?
Or to state it more generally: It is desirable to standardize both an
Information Model and an API to that model. The Information Model need not
be implemented as specified; instead, the API must be implemented.
Conformance would be determined with respect to the API only, not to any
implementation of the Information Model.
-- Len

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

Powered by eList eXpress LLC