Re: Regrep data integrity

[Terry Allen <tallen@sonic.net>]

Thanks for the quick response, Lisa.
| 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.  

Good.  Then we're set.

| 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)

Ah, good.  We missed that; "Persistence" is about saying how long you
expect to stay in business.  It's perhaps implied by the statement
about "INTEGRITY" in repreqs.htm,

"The system must maintain data integrity (consistency, referential 
integrity)."

but it probably should be specified better and this whole nonnormative
document should be scoured for what should go into the normative spec.
And I'm not sure what referential integrity is.

| A meta-data application conforms to LOM if it satisfies the following two
| requirements: 
| (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?

While min-max lengths appear (I think) as possibilities in XML Schema,
for DTDs they don't apply to PCDATA.  The problem covered above arises
when you depend on a database that has max lengths; I recall one of
our engineers asking me how long a name can be.  I asked him if
we had any Indonesian customers ...

I'd prefer not to specify max lengths even if we move to Schema,
but I can see that some applications will choke on an excess of 
PCDATA.

| 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.

This was part of what I was trying to get at in "I2C and I2X proposal":  
extend as you like, but write your own DTD for it, and be able to
return an OASIS-compliant metadata record (presumably with a link
for obtaining the full extended metadata record).  That seems the
simplest approach to me; think about it and see what you decide.


regards, Terry