Regels / afspraken tekstvelden

[ElisabethKloren]

Welke regels / afspraken zijn nodig om te zorgen dat input in tekstvelden niet als code wordt gezien in csv, xml, turtle/JSON?

"of het ontstaan van %#@# gekke tekens in de teksten omdat de ene applicatie uitgaat van html en de andere van platte tekst."

NR zegt: Helpt het om in het uitwisselformaat eisteksten en dergelijke altijd tussen quotes te zetten? Zodat de speciale tekens als tekst worden gezien?

KJW zegt: In contracten waar installaties zoals bijvoorbeeld tunnelinstallaties in de scope zitten worden soms codes voorgeschreven in eisteksten. Dit bijt met deze regel. Ter discussie: hoe dient om te gaan te worden met programmeringscodes van software in eis specificaties?

[RiX012]

@redmer Is wel een goeie vraag. Kun jij hier iets over zeggen?

[Kees-JensvdWel]

Houd er rekening mee dat het voorkomt bij contracten met technische installaties in de scope (zoals tunnelinstallaties) dat codes opgenomen worden in de eisteksten. Indien gekozen wordt om bepaalde karakters te vermijden in eisteksten dient hier iets opgenomen voor te worden zoals een verwijzing naar een document met de codes (geniet mijn voorkeur).

[ElisabethKloren]

En KJW zegt: Wellicht verstandig om hier een maximaal aantal characters op te nemen voor het veld eistekst. Met name bij processpecificaties wilt een stakeholder soms lange teksten opnemen wat niet ten goede komt voor de verificatie en beheersing. Wel geloof ik dat dit een opvoeding is van de sector. Voorstel van maximaal aantal tekens is 2000.

[rense-k]

Veel opdrachtnemers zullen hun contract in Relatics willen opnemen. Kan handig zijn om de limieten daarvan niet de overschrijden. Dat voorkomt dat een aangeleverde eis opgesplitst moet worden, omdat bijv. de eistekst te lang is.

Globaal heeft Relatics deze limieten (hangt ook af hoe ON zijn informatiemodel heeft opgebouwd):

• Naam: max 255 tekens
• Beschrijving (zoals eistekst): max 2000 tekens
• Eigenschapswaarden (zoals codes): max 2000 tekens

Bron: https://kb.relaticsonline.com/published//ShowObject.aspx?Key=1397c31c-b252-e311-93f9-00155d5f2f05

[redmer]

Welke regels / afspraken zijn nodig om te zorgen dat input in tekstvelden niet als code wordt gezien in csv, xml, turtle/JSON?

Als je de teksten ze gaat distribueren als CSV/XML/JSON/Turtle, dan hebben ze allemaal een optie om tekst, tekst te laten zijn en speciale tekens niet te laten interpeteren als einde-cel.

• CSV: Verschillende specificaties, vaak is \" of "" de escape om het enkele aanhalingsteken als tekst te interpreteren en niet als einde-cel
• XML heeft CDATA, waarbij opmaak-achtigen als character data worden geïnterpreteerd (![CDATA[<greeting>Hello, world!</greeting>]] maakt de greeting-tags tot tekst).
• JSON gebruikt \" om een aanhalingsteken tekst te laten zijn (en niet einde-veld).
• Turtle gebruikt eveneens \", maar kan ook """..."""" gebruiken als string delimiter (die ook newlines ondersteunt).

Ik durf wel te stellen dat elke CSV/XML/JSON-verwerkende library deze escapes ondersteunt. Naïeve verwerking van CSV-regels (zie hieronder) is sowieso niet een goed idee, omdat niet volgens spec de data wordt geparseerd. Dat komt dan wel aan het ligt met je "speciale tekens".

Voorbeeld

Gegeven de tabel:

c1	c2	c3
waarde	waarde, 2	waarde "e"

zou de eerste dataregel foutief als e.g. '"waarde","waarde, 2","waard \"e\""'.split(",").replace('"', "")) verwerkt kunnen worden. Dat is niet volgens spec, maar werkt bij simpele data voldoende. (Eerst splitsen op kolomscheider, daarna celdelimiters verwijderen.) Dat zou leiden tot de waardes:

• waarde
• waarde
• 2
• waard \e\

[redmer]

Specificaties

• Voor XML: https://www.w3.org/TR/xml/ (Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008)
• Voor JSON: https://www.ecma-international.org/publications-and-standards/standards/ecma-404/ (ECMA-404: The JSON data interchange syntax, 2nd edition, December 2017)
• Voor Turtle: https://www.w3.org/TR/turtle/ (RDF 1.1 Turtle: Terse RDF Triple Language. W3C Recommendation 25 February 2014)
• Voor CSV is er geen formele specificatie, meer een vage nevel van parsers. Maar je zou kunnen refereren aan https://github.com/parsecsv/csv-spec/blob/master/csv-spec.md.

[ElisabethKloren]

@redmer dit is top; weet je zeker dat hier geen specificaties tussen staan: https://www.w3.org/2013/csvw/wiki/Main_Page , waaronder https://www.w3.org/TR/2015/REC-tabular-data-model-20151217/

[redmer]

Merci! Die links van CSVW zijn wel een technische specificatie waar je naar kunt verwijzen voor je conformiteit -- dat je zegt, je CSV moet voldoen aan de voorwaarden gesteld in x, y, z -- maar het zijn niet de formele, constituerende specificaties voor alle CSV-bestanden.

Ik bedoel: Turtle is alleen Turtle als het conform de W3C REC is. Idem voor JSON conform de ECMA 404. Voor CSV moet je helaas explicieter zijn.

[ElisabethKloren]

Deze basisregels zijn opgenomen in de tekst, inclusief voorbeelden van Redmer