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

 > Date: Tue, 28 Mar 2000 15:48:28 -0800
 > From: Terry Allen <tallen@sonic.net>
 	... snip ...
 > | 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 
 > | 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 
 > 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 
 I agree with Terry. Besides, I don't think length ( I presume you
 meant 'byte length' by that) does help much for the data preservation.
 If you want to do this kind of things, you need to send a check sum.
 > | 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.
 Again, I agree with Terry. We can make an 'extension', a sort of
 metadata of metadata(if I may say), and still the elements could
 be covered by data element attributes in 11179 [part3 4].
 Actually, when I think about data integrity, it confuses me in terms of
 whether I'm thinking of data preservation, like Lisa mentioned,
 or I'm thinking of security and provenance. So, I'd like to
 separate it into two. For the former, we might be able to apply iso 9796,
 using digital signature scheme for data recovery, and for the latter,
 how about iso 9797, using a cryptographic check for data integrity.
 But I'm afraid it is beyond the regrep spec to mention them.

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

Powered by eList eXpress LLC