Specifikation med krav

[KristoferGa]

Contact Details

No response

What benefits does the suggestion solve?

Nuvarande utkast av specifikationen innehåller inga krav utan endast rekommendationer. Konsekvensen är att man kan säga att man följer specifikationen utan att egentligen ha uppnått något.

Är det inte bättre att ha en specifikation som innehåller krav (och rekommendationer)? Som utformningen är idag kan inte en grunddatadomän peka på specifikationen och säga att den SKA följas, för att uppnå något. Huruvida man sedan vill använda specifikationen (eller delar av den) kan man ju själv välja (om inte någon annan bestämmer det).

Feature suggestion description

Beskriv krav.

Alternative solutions

No response

Additional information

No response

[salgo60]

Håller med 200% tycker det 20 åriga försöket med persistenta identifierare för myndigheters författningar som inte levereras borde peka på att DIGG måste

• vara enormt tydlighet vad som gäller
• ha en tidplan
• uppföljning av status med mer seniora projektledare än projektet ovan
• enhetligt sätt att felrapportera till myndigheter så problem fångas upp snabbt och att man snabbt kan fånga när någon underlevererar...

tycker mig redan se red alert på denna projektyta när saker inte besvaras...

[matthiaspalmer]

Detta ärende har stort överlapp med #6.

Ett förslag är att skriva om de nedan som är i fetstil som krav:

• BI1 - Använd http eller https
• BI2 - Använd domännamn, inte IP adresser i URL:er
• BI3 - Undvik portnummer, användarnamn eller lösen i URL:er
• BI4 - Undvik frågeparametrar
• BI5 - Undvik fragment
• UM1 - Använd DNS för domännamn, sen http
• UM2 - Använd HTTP HEAD för information om företeelsen
• UM3 - Använd HTTP GET för uppslagning av informationsresurser
• UM4 - Använd Accept, accept language osv. för att få rätt representation
• UM5 - Använd Accept-profile för att särskilja representationer i samma format
• UM6 - Använd 307, temporär redirect vid behov
• UM7 - Använd 303 för att peka ut beskrivningar för företeelser
• UM8 - Använd link describedby för ytterligare beskrivningar
• UM9 - Använd link alternate för att peka ut en uppslagningstjänst för multipla beskrivningar
• UM10 - Använd 410 för beständiga identifierare som tagits bort
• UM11 - Använd 308 för att peka ut en identifierare som ersätter den nuvarande

[salgo60]

Publicera dessa krav som Öppen data med Persistenta identifierare.... gärna med flerspråkighet så vi kan koppla ihop olika länders PID krav.... och att projekt som K-samsök 2.0 kan peka på vilka krav dom implementerar och hur... --> vi skulle kunna snabbt ha en lösningsbank hur olika krav implementeras och kanske på sikt kunna koppla det till Open source lösningar och enkelt visa upp en matrix vilka krav som implementeras med olika lösningar.... och hur dom tillgodoser olika länders/EU ställda krav

[matthiaspalmer]

Möte 3 beslutade att denna är löst genom uppdelning i SKALL, BÖR och KAN krav i kombination med en förtydling vad det innebär att följa specifikationen.