[Bitrepository-devel] Tomme elementer.

Jonas Lindberg Frellesen jolf at kb.dk
Tue Feb 7 17:45:23 CET 2012


For at undgå at lave en fuldstændig lukket definition af hvilke checksummer, som protokollen skal tillade, kan man kigge lidt på, hvordan de store metadata skemaer definerer standarder, men samtidig åbner op for udvidelser.
I eksempelvis METS, hvor man kan indlejrer andre metadata formater, er der følgende restriktion:
                <xs:restriction base="xs:string">
                    <xs:enumeration value="MARC"/>
                    <xs:enumeration value="MODS"/>
                    <xs:enumeration value="EAD"/>
                    <xs:enumeration value="DC"/>
                    <xs:enumeration value="NISOIMG"/>
                    <xs:enumeration value="LC-AV"/>
                    <xs:enumeration value="VRA"/>
                    <xs:enumeration value="TEIHDR"/>
                    <xs:enumeration value="DDI"/>
                    <xs:enumeration value="FGDC"/>
                    <xs:enumeration value="LOM"/>
                    <xs:enumeration value="PREMIS"/>
                    <xs:enumeration value="PREMIS:OBJECT"/>
                    <xs:enumeration value="PREMIS:AGENT"/>
                    <xs:enumeration value="PREMIS:RIGHTS"/>
                    <xs:enumeration value="PREMIS:EVENT"/>
                    <xs:enumeration value="TEXTMD"/>
                    <xs:enumeration value="METSRIGHTS"/>
                    <xs:enumeration value="ISO 19115:2003 NAP"/>
                    <xs:enumeration value="OTHER"/>

(http://www.loc.gov/standards/mets/mets.xsd)

Her er en lang række forskellige metadata formater, som man kan indlejre, men den er ikke lukket, da den også indeholder værdien 'OTHER', samt et ekstra felt hvor man som "String" kan fortælle hvillket metadata format, der så er tale om.


Altså i vores tilfælde ville det være følgende:
<xs:restriction base="xs:string">
  <xs:enumeration value="MD5" />
  <xs:enumeration value="SHA1" />
  <xs:enumeration value="SHA256" />
  <xs:enumeration value="SHA384" />
  <xs:enumeration value="SHA512" />
  <xs:enumeration value="HMAC-MD5" />
  <xs:enumeration value="HMAC-SHA1" />
  <xs:enumeration value="HMAC-SHA256" />
  <xs:enumeration value="HMAC-SHA384" />
  <xs:enumeration value="HMAC-SHA512" />
  <xs:enumeration value="OTHER" />
</xs:restriction>
Samt et ekstra felt, f.eks. 'OTHERCHECKSUM', hvor man kan skrive sin 'OTHER' som en ikke-begrænset string.

På den måde begrænser vi ikke andre i at bruge protokollen, men samtidig definerer vi klart, hvilke checksums algoritmer som vi i det danske bitmagasin vil benytte os af.


Med venlig hilsen
Jonas

-----Oprindelig meddelelse-----
Fra: bitrepository-devel-bounces at ml.sbforge.org [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Kim Teglgaard Christensen
Sendt: 7. februar 2012 10:20
Til: Michael Rasmussen
Cc: bitrepository-devel at ml.sbforge.org
Emne: Re: [Bitrepository-devel] Tomme elementer.

Jeg tror ikke det er hensigtsmæssigt på protokol niveau at definere
hvilke checksum algoritmer vi kan anvende. Der findes jo et hav af
sådanne og definere i protokollen hvilke der er mulige vil for mig at se
ikke være så heldig. 

- Kim

On Tue, 2012-02-07 at 08:51 +0000, Michael Rasmussen wrote:
> Skal/kan der så også svares tilbage med tomme elementer, eller hvordan? Er det alle steder, hvor der er valgfrie elementer, at de må være tomme (så længe xml'en validerer)?
> 
> Mht. tolkning af tom checksumsalt er begge versionen OK med mig, bare det er defineret. Jeg tror dog det kunne være en fordel at lave checksumtype til en enumeration, hvor der skelnes mellem MD5 og HMAC-MD5.
> 
> ~ Michael
> 
> 
> -----Original Message-----
> From: bitrepository-devel-bounces at ml.sbforge.org [mailto:bitrepository-devel-bounces at ml.sbforge.org] On Behalf Of Mikis Seth Sørensen
> Sent: Tuesday, February 07, 2012 8:48 AM
> To: List for the Bitrepositorys developers
> Subject: Re: [Bitrepository-devel] Tomme elementer.
> 
> Jeg syntes vi skal prøve at lade være med at bruge tomme elementer. Når
> det så er sagt skal der stadigvæk kodes som at de andre kan finde på det.
> 
> Hvis man vil undgå at skrive:
> request.getChecksumRequestForNewFile() != null &&
> request.getChecksumRequestForNewFile().getChecksumType().trim().length() >
> 0
> kan man jo lave en metode til at indkapsel forskellige måder at skrive
> 'Ingen checksum request'
> private boolean isChecksumRequestDefined(ChechsumSpecTYPE spec) {
>   return
>     request.getChecksumRequestForNewFile() != null &&
> request.getChecksumRequestForNewFile().getChecksumType().trim().length() >
> 0 &&
>     .........;
> }
> 
> 
> Mvh
> Mikis 
> 
> 
> On 07/02/12 08.26, "Kim Teglgaard Christensen" <ktc at statsbiblioteket.dk>
> wrote:
> 
> >Hej
> >
> >Jeg er selv ude i at checke på om elementerne er null og om de har
> >længden 0. Da jeg ser et tomt element som værende ikke eksisterende.
> >
> >Angående et tomt salt element vil jeg mene at det skal tolkes på samme
> >måde, som at det er null.
> >Altså at null eller længde 0 element skal medføre almindelig checksum.
> >
> >Men det kan da godt være at webclienten skal laves om så der ikke bliver
> >sat tomme elementer?
> >
> >Mvh Kim
> >
> >On Mon, 2012-02-06 at 15:54 +0000, Michael Rasmussen wrote:
> >> Hejsa.
> >> 
> >>  
> >> 
> >> Jeg kan se, at webclienten, når extra checksummer
> >> (ChecksumRequestFor*File) er ²disabled², stadig sender elementerne
> >> med:
> >> 
> >>  
> >> 
> >> 
> >><ChecksumRequestForNewFile><ChecksumType></ChecksumType><ChecksumSalt></C
> >>hecksumSalt></ChecksumRequestForNewFile>
> >> 
> >>  
> >> 
> >> Er dette tilladt eller er det bare en forglemmelse?Jeg vil helst undgå
> >> at 
> >> 
> >>  
> >> 
> >>             if (request.getChecksumRequestForNewFile() != null) {
> >> 
> >>  
> >> 
> >> skal blive til..
> >> 
> >>  
> >> 
> >>             if (request.getChecksumRequestForNewFile() != null &&
> >> 
> >>request.getChecksumRequestForNewFile().getChecksumType().trim().length()
> >>> 0) {
> >> 
> >>  
> >> 
> >> alle steder, hvor noget sådant kan optræde.
> >> 
> >>  
> >> 
> >> I samme forbindelse: Hvordan skal udeladt/tomt ChecksumSalt element
> >> opfattes? Jeg anlægger p.t. følgende tolkning:
> >> 
> >>  
> >> 
> >> Intet ChecksumSalt element => alm. checksum  (f.eks. MD5)
> >> 
> >> Tomt ChecksumSalt element => HMAC med salt = byte[] { 0 }
> >> 
> >>  
> >> 
> >> Hvilket betyder at det ikke er muligt at få en ikke-HMAC checksum ud
> >> med webklienten.
> >> 
> >>  
> >> 
> >> ~ Michael
> >> 
> >>  
> >> 
> >>  
> >> 
> >> http://support.kb.dk/images/kb_logo.jpg
> >> 
> >> 
> >> Det Kongelige Bibliotek
> >> Nationalbibliotek og Københavns
> >> Universitetsbibliotek
> >> 
> >> 
> >> Michael Rasmussen
> >> IT-Konsulent/Civil værnepligtig |
> >> Consultant
> >> 
> >> Det Kongelige Bibliotek | The Royal
> >> Library
> >> Digital Infrastruktur og Service |
> >> P.O. Box 2149 | DK-1016 København K
> >> tel +45 3347 4574 | Fax +45 3393
> >> 2218 | mira at kb.dk | www.kb.dk
> >> 
> >> Besøgsadresse | Visiting address |
> >> Søren Kierkegaards Plads 1
> >> Leveringsadresse | Delivery address
> >> | Christians Brygge 8 | 1219
> >> København K
> >> 
> >> EAN 5798 000 79 52 97 | Bank 0216
> >> 4069032583 | CVR 28 98 88 42
> >> IBAN DK2002164069032583 | Swiftcode
> >> DABADKKK
> >> 
> >> 
> >> 
> >>  
> >> 
> >> 
> >
> >
> >_______________________________________________
> >Bitrepository-devel mailing list
> >Bitrepository-devel at ml.sbforge.org
> >http://ml.sbforge.org/mailman/listinfo/bitrepository-devel
> 
> 
> _______________________________________________
> Bitrepository-devel mailing list
> Bitrepository-devel at ml.sbforge.org
> http://ml.sbforge.org/mailman/listinfo/bitrepository-devel
> 
> _______________________________________________
> Bitrepository-devel mailing list
> Bitrepository-devel at ml.sbforge.org
> http://ml.sbforge.org/mailman/listinfo/bitrepository-devel


_______________________________________________
Bitrepository-devel mailing list
Bitrepository-devel at ml.sbforge.org
http://ml.sbforge.org/mailman/listinfo/bitrepository-devel



More information about the Bitrepository-devel mailing list