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: Re: Regrep data integrity

The statement that Terry writes below that specifies "that a 'data
integrity' policy should exist and be published" is correct, I think,  for
this specification.  To require  more than that (i.e., to require a
'defined' security policy and mechanisms (e.g., digital signatures)) is
beyond the scope of our specification and should be implementation-defined.
  The IMS meta-data specs do not address data integrity; however there may
be a different IMS spec that does.  

NEW ISSUE: On the same but actually different note,  the issue that I
wanted to raise in the conference call was not 'data integrity' as Terry
defines it below, but rather data 'preservation'. (I'll stick with using
'data integrity' in the security context.)   Our specification should state
that a registry will return, without loss or error, the metadata that was
submitted/agreed to by the SO.  IMS has a few good statements in their
spec:  (LOM is learning object meta-data)

A meta-data application conforms to LOM if it satisfies the following two
(Only one is listed here [Lisa]): ...If an application receives a
conforming LOM meta-data instance, stores it, and then transmits it, then
the application preserves the original meta-data instance during
retransmission. The application is not required to preserve elements beyond
the min-max items of a list or the characters beyond the min-max of a string. 
Caveat: Preservation means that the original instance is not changed in any
way. i.e. that it "doesn't change a comma".
End of IMS spec.

This raises the issue of specifying min-max lengths on fields.  Any ideas?

NEW ISSUE: Extensions
An extension is used here in the context of 'extending the meta-data'.
That is, a submitter might want to register an item and provide meta-data
that is beyond that which is specified by the OASIS specification.  A
possible solution is to add an EXTENSION element.  However I don't think an
OASIS- compliant registry would have to 'handle' the extension beyond
storing it so that it can be returned based on a query.  Any ideas?

If folks think these are reasonable concepts to have in the specification I
will volunteer to put some language together.


At 12:21 PM 03/28/2000 -0800, you wrote:
>Working through Lisa's suggestions from the face-to-face,
>I've arrived at "data integrity".  ISO 11179 doesn't directly
>deal with data integrity, although it does say that a RA
>is "responsible for maintaining the register of data
>elements" (Part 6, 5.2.3) and "take all reasonable
>precautions to safeguard the register" (Part 6, 5.3.3).
>The spec currently says (and I've moved this language into
>the Tech Spec per Lisa's suggestion):
>"The registry and repository shall have published policies 
>relating to their use of methods to guarantee the integrity of 
>entities in repository and metadata in the registry; for example,
> does the repository employ digital signatures to ensure against
> corruption? if transformations of registered entities are served 
>are they signed as well?"
>I'm not sure we need those examples, but in any event I'd
>welcome substitute text.  Lisa, what does the IMS spec say
>about data integrity?
>regards, Terry

Lisa J. Carnahan
National Institute of Standards and Technology
Information Technology Laboratory
Room 562, Bldg. 820
Gaithersburg, Md. 20899

(301) 975-3362 voice 
(301) 948-6213 fax

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

Powered by eList eXpress LLC