Telexanschlusstyp kenntlich machen

[FredSonnenrein]

Dann beherzige ich mal deinen Rat:

Code: Alles auswählen

@([^,]*)(, ?([^:(]*)( \([^:]*\))?)?( ?:[^=]*)?( ?=[a-z]*)?@gm

Der ist eh besser, der vorherige hatte einen kleinen Fehler. (Dieser hier möglicherweise auch, aber ich seh ihn nicht.)

Irgendwie sind mir da zu viele ? drin.
Wäre das nicht besser:

Code: Alles auswählen

@([^,:=]*)   (,[^:\(=]*(\([^:=\)]*\))?)?   (:[^=]*)?   (=[a-z]*)?@gm

Was macht eigentlich @gm ?
Und die Leerzeichen am Ende der Teile müssten noch extrahiert werden... Achtung: Es kann auch bestimmten Gründen vorkommen, dass ich mehr als ein Leerzeichen einbauen muss!

[TheRaph]

Hi Fred.

Dann beherzige ich mal deinen Rat:

Code: Alles auswählen

@([^,]*)(, ?([^:(]*)( \([^:]*\))?)?( ?:[^=]*)?( ?=[a-z]*)?@gm

Der ist eh besser, der vorherige hatte einen kleinen Fehler. (Dieser hier möglicherweise auch, aber ich seh ihn nicht.)

Irgendwie sind mir da zu viele ? drin.
Wäre das nicht besser:

Code: Alles auswählen

@([^,:=]*)   (,[^:\(=]*(\([^:=\)]*\))?)?   (:[^=]*)?   (=[a-z]*)?@gm

Möglich ... allerdings bitte ohne die LZ.
Dein Vorschlag matched nicht alles (z.B. nicht "Sean, St. Ippolyts (UK) :FS200").

Screenshot 2022-06-13 171733.png

Das Problem, zwischen dem ")" und dem ":" kann noch ein Leerzeichen liegen, das nicht abgefangen ist. Das fällt bei den Deutschen nicht auf, weil das LZ beim Ort mit beaufschlagt wird.

Allerdings hast du recht, da sind noch einige " ?" drin, die ein optionales LZ abfragen, die können natürlich in den Capture-Groups mit untergehen.
Außerdem brauchen wir für "Ort inkl. Staat" keine daten - das kann einen "non-capturing group" werden.

Hier die Optimierung:

Code: Alles auswählen

@^([^,:=]*)(?:,([^:=(]*)( \([^:=]*\))?)? ?(:[^=]*)?(=[a-z]*)? *$@gmU

Screenshot 2022-06-13 172809.png

Was macht eigentlich @gm ?
Und die Leerzeichen am Ende der Teile müssten noch extrahiert werden... Achtung: Es kann auch bestimmten Gründen vorkommen, dass ich mehr als ein Leerzeichen einbauen muss!

gm steht für Global und Multiline ... macht nur Sinn, wenn man die Komplette Liste mit allen Tln. mit einmal bearbeiten möchte. Allerdings muss dann noch ein "U" für ungreedy hin. ... Ich glaube das ist PHP-Syntax. Man kann das wohl auch als (?gmU) vorne weg schreiben.
Und das "@" ist der Delimiter.

Raph

Edit: kleiner Fehler ist noch drin im RegEx. Ich bin bloß unterwegs. Korrektur folgt.

[Fernschreiber]

Hallo an die, welche hier noch mitlesen.,

Seit 50 #en diskutieren wir jetzt hier rum, ich hatte mich mit Fred's Anpassungen und neuen Definitionen arrangiert und das Ziel, den Ort vernünftig zu isolieren war erreicht. Die wenigen Nebenwirkungen wären auch noch ausgemerzt worden. Jetzt plötzlich tritt ein Umdenken ein und längst beschriebene Grundprobleme werden angepackt. Die Zeit und Mühen der letzten Tage 12 Tage sind damit größtenteils hinfällig.
Wir sind also wieder bei #3 und diskutieren verschiedene Trennzeichen. Eine feste Struktur, die nach hinten erweiterbar ist, braucht zwar auch ein Trennzeichen, aber ein einheitliches. Warun geht in kleinen nicht, was im gesamten Datensatz sehr gut funktioniert.

Zitat:
Der Text im Teilnehmerverzeichnis auf den Servern wird nur von Martin, Henning und mir vergeben. Die Benutzer müssen sich "fügen".
Zitatende

Dieser Satz spricht ja Bände. Wieso gibt es dann das Problem mit den Romanen und der daraus folgenden Byteknappheit?

Zitat:
Meine Meinung zur PLZ: Als alleiniges Merkmal STATT Ortsnamen finde ich es blöd.
Zitatende

Davon war nie die Rede, es wurde immer als das erwähnt, was in Folgesatz geschrieben wurde;

Zitat:
Als Ersatz für lange Zusatzbezeichnungen finde ich es OK.
Zitatende


Zitat:
"Allerdings könntest du die das Leben vereinfachen. "
Zitatende

Ja mache ich, kein (Python-) Code mehr hier im Form.

Da ich heute den Überblick verloren habe, was Stand der Dinge ist, wäre es sinnvoll mal einen Schnitt zu machen um aufzulisten wie der Aufbau nun sein soll, was optional ist und wie die Regeln der Inhalte sind. Wichtig: was ist fix und worüber ist noch zu reden/schreiben. Und wenn, dann bitte praktische Beispiele benutzen.
Nun, der neue Ansatz geht ja in meine Wunschrichtung, daher bleibe ich aktiv an Board. Aber bei 100 ist Schluß,

Gruß
Willi

[TheRaph]

Moin Moin.

...

Hallo an die, welche hier noch mitlesen.,

...

Da ich heute den Überblick verloren habe, was Stand der Dinge ist, wäre es sinnvoll mal einen Schnitt zu machen um aufzulisten wie der Aufbau nun sein soll, was optional ist und wie die Regeln der Inhalte sind. Wichtig: was ist fix und worüber ist noch zu reden/schreiben. Und wenn, dann bitte praktische Beispiele benutzen.
Nun, der neue Ansatz geht ja in meine Wunschrichtung, daher bleibe ich aktiv an Board. Aber bei 100 ist Schluß,

Letzter Stand (teilw. Zitat Fred):

Regeln für die Benennung
1. Länge 40 Zeichen
2. Trennzeichen sind in den "Nutzdaten" nicht erlaubt
3. Trennzeichen sind obligatorisch WENN das entsprechende "Datenfeld" nicht leer ist.
4. Reihenfolge ist: Vorname, Ort, Land, Maschinentyp, Merkmale
5. Name ist Pflicht.
6. Trennzeichen "," trennt den Ort ab
7. In Ort dürfen keine Klammern sein (außer 8.)
8. Im Ort muss bei allen Nicht-deutschen das Länderkürzel hinter dem Ortsnamen in Klammern stehen "New York (USA)"
9. Trennzeichen ":" trennt den Maschinentyp ab (hier ist wieder alles erlaubt - auch nähere Beschreibung z.B. "T100 Werkstatt")
10. Trennzeichen "=" trennt die Merkmale ab
11. Leerzeichen vor und nach den Trennzeichen sind empfohlen aber nicht verpflichtend.

Etwa so:

Code: Alles auswählen

<Vorname>[,[ <Ort>][ (<Land>)]][ :<Maschinentyp>][ =<Merkmale>]

Was davon Fest ist und was noch zur Diskussion steht weiß ich nicht.

509 Beispiele sind im Anhang. Es ist das Maximum an Beispielen was möglich ist (alle Mitglieder der KLKL-Liste).

Ich bin die KLKL-Liste (vom sonnibs - Server) anhand der zuvor genannten Regeln (die wahrlich nur ein Kompromiss waren) durchgegangen.
Ca. 85% ließen sich automatisch zuordnen. Allerdings gab es etliche Verwerfung:
- FS-Typ "PC", "Minitelex", "PiTelex" oder ähnliches enthielten weder ein : noch eine Zahl
- Einige FS-Beschreibungen enthielten Leerzeichen
- Es gibt FS-Beschreibungen die / enthalten
uvm.

Ich habe die Liste per Hand nachberabeitet.

Im Anhang 2 Datein.
KLKL-neu.txt ... Mein Vorschlag für die Umsetzung ins neue Schema unter möglichst viel Beibehaltung dessen was drin stand.
KLKL-chk.txt - Die Überprüfung mit dem RegEx:

Code: Alles auswählen

@(?U)^([^,:=]*)(?:,([^:=(]*)( \([^:=]*\))?)? ?(:[^=]*)?(=[a-z]*)? *$@

Und die Ermittelte Gruppierung daraus.
Kann mit Excel (Tabulator getrennt) geöffnet werden

Viel Spaß beim Lesen.

KLKL-Neu.txt

KLKL-chk.txt

Für Fehler übernehme ich die alleinige und Vollständige Verantwortung. (Und trete ggf. von allen Ämtern zurück, wenn ich mich nicht rausreden kann.)

Raph

[FredSonnenrein]

Moin Moin

Hallo Raph,

vielen Dank für die tolle Arbeit!
Du hast die Regeln perfekt zusammengestellt, dennoch ein paar Ergänzungen von mir (in roter Schrift):

Regeln für die Benennung
1. Länge 39 Zeichen Korrektur 15.06.2022: (leider gibt es bei 40 Zeichen Probleme bei der Synchronisation)
2. Trennzeichen sind in den "Nutzdaten" nicht erlaubt
3. Trennzeichen sind obligatorisch WENN das entsprechende "Datenfeld" nicht leer ist.
4. Reihenfolge ist: Vorname, Ort, Land, Maschinentyp, Merkmale
5. Name ist Pflicht.
6. Trennzeichen "," trennt den Ort ab
7. In Ort dürfen keine Klammern sein (außer 8.)
8. Im Ort muss bei allen Nicht-deutschen das Länderkürzel hinter dem Ortsnamen in Klammern stehen "New York (US)" Das Länderkürzel wird nach ISO 3166-1 Variante ALPHA-2 vergeben
9. Trennzeichen ":" trennt den Maschinentyp ab (hier ist wieder alles erlaubt - auch nähere Beschreibung z.B. "T100 Werkstatt")
10. Trennzeichen "=" trennt die Merkmale ab
11. Leerzeichen vor und nach den Trennzeichen sind zur Verbesserung der menschlichen Lesbarkeit empfohlen aber nicht verpflichtend.
12. Eine Länderangabe ist nur in Verbindung mit einer Ortsangabe erlaubt

Was davon Fest ist und was noch zur Diskussion steht weiß ich nicht.

Alles steht noch zur Diskussion, aber ich vermute dass wir schon fast am Ende sind.
Deine Beispiele sehen so gut aus, dass nach meiner Auffassung diese Regeln auch genau so bleiben können.

Mir sind noch zwei zusätzliche Merkmale eingefallen:
u für Maschine mit US-TTY Zeichensatz
k für Maschine mit 3. Ebene Kyrillisch

Nun zu Willi: Ich kann etwas verstehen, dass du ein bischen angefressen bist. Ich möchte es dir erklären:

Seit 50 #en diskutieren wir jetzt hier rum, ich hatte mich mit Fred's Anpassungen und neuen Definitionen arrangiert und das Ziel, den Ort vernünftig zu isolieren war erreicht. Die wenigen Nebenwirkungen wären auch noch ausgemerzt worden. Jetzt plötzlich tritt ein Umdenken ein und längst beschriebene Grundprobleme werden angepackt.

Ziel ist ganz klar: Kompromissfindung um eine maschinelle "Zerlegbarkeit" des Eintrags zu erreichen und dabei die Lesbarkeit für den Menschen so wenig wie möglich zu beeinträchtigen. Die Priorität bei dieser Kompromissfindung habe ich nochmal fett unterstrichen markiert. Und zur Lesbarkeit gehört auch eine gewisse Ästhetik.

Die Zeit und Mühen der letzten Tage 12 Tage sind damit größtenteils hinfällig.

"Größtenteils" kann ich nicht nachvollziehen. Der Teil mit der Erkennung zweier Ziffern im Maschinentyp vielleicht. Aber es wurden Beispiele aufgezeigt, die diesen Ansatz als Sackgasse offenbarten.

Wir sind also wieder bei #3 und diskutieren verschiedene Trennzeichen. Eine feste Struktur, die nach hinten erweiterbar ist, braucht zwar auch ein Trennzeichen, aber ein einheitliches. Warun geht in kleinen nicht, was im gesamten Datensatz sehr gut funktioniert.

Dieses einheitliche Trennzeichen ist genau das, was mich bei dem Kriterium Ästhetik stört. Ein Eintrag in der Form

Code: Alles auswählen

Rudis Museum, , , , z

sieht mehr als doof aus.
Ja, über Ästhetik lässt sich streiten. Ich pflege die Teilnehmerliste, ich lege daher meine Maßstäbe an.

Zitat
Der Text im Teilnehmerverzeichnis auf den Servern wird nur von Martin, Henning und mir vergeben. Die Benutzer müssen sich "fügen".
Zitatende
Dieser Satz spricht ja Bände. Wieso gibt es dann das Problem mit den Romanen und der daraus folgenden Byteknappheit?

Weil ich selbstverständlich die Wünsche des Anwenders soweit möglich erfülle.

Da ich heute den Überblick verloren habe, was Stand der Dinge ist, wäre es sinnvoll mal einen Schnitt zu machen um aufzulisten wie der Aufbau nun sein soll, was optional ist und wie die Regeln der Inhalte sind. Wichtig: was ist fix und worüber ist noch zu reden/schreiben. Und wenn, dann bitte praktische Beispiele benutzen.

Siehe oben. Fix ist gar nichts. Selbst wenn wir es morgen als fix erklären, kann es übermorgen gute Gründe geben, dies wieder zu ändern.
Es sei dir aber versichert, dass die Gründe "übermorgen" (bitte nicht wörtlich nehmen) schon sehr stichhaltig sein müssten.

Nun, der neue Ansatz geht ja in meine Wunschrichtung, daher bleibe ich aktiv an Board. Aber bei 100 ist Schluß,

Versprochen.

Noch ein Tipp für Willi: Ich denke, dass wesentliche Teile deines Codes weiterhin verwendbar bleiben.
Du musst nur das / durch das = ersetzten.
Und zur Kompensation der neuen Regel "Leerzeichen sind optional" könntest du einfach im ersten Schritt alle : durch "Leer :" ersetzten und alle "=" durch "Leer =". Dann kannst du wieder an den Leerzeichen trennen. Die Anzahl der Leerzeichen war zu keinem Zeitpunkt der Diskussion definiert.

Viele Grüße,

Fred

[Fernschreiber]

Hallo zusammen,

@ Raphael:
Dein Bemühen in allen Ehren, aber wenn Du eine selbsgenerierte Inputliste mit deiner eigenen Auswertung testest, muss das ja funktionieren.
Die Zeile "122267 Anders, Turku (FI) Testplatz Fehler" sehe ich daher als gewollten Negativtest an.

Die Beispiellisten mit KLKL zu benamen, hat mich verwirrt, da dieser Begriff hier noch nie benutzt wurde. Die KLKL-Liste ist eine Untermenge der Tln-Serverliste und hat natürlich die gleichen Parameter aus dem Namenfeld. Diese variiert natürlich dadurch, das sie von Detlef verwaltet wird und nur Hauptrufnummern von Teilnehmern enthält. Dies werden auf Erreichbarkeit geprüft, ebenso fehlen dort sämtliche Dienste. Also nicht verwechseln.

Die folgenden Punkte interessieren mich auswertetechnisch nicht, Name/Ort/Land sind meine Suchbegriffe, mehr nicht.

In der Inputliste sind mir aber einige Punkte aufgefallen, die eingabetechnischer Natur sind und von Dir so übernommen oder deklariert wurden.
1) "952532","MAKERFAIRE HANNOVER 2016","5","","77.21.126.119","134","" wurde zu : 952532 MAKERFAIRE HANNOVER :2016
folgerichtig ist der Maschinentyp jetzt 2016. Als Ursprungsangabe sollte lieber " MAKERFAIRE2016 , HANNOVER "stehen und alles wäre richtig.

2)"16367","Micha, Beelitz offline","5","","87.187.157.239","134","" wurde zu : 16367 Micha, Beelitz :offline ob das wirklich als Maschinentyp zu bezeichnen ist, ist fraglich. Für so etwas bietet sich doch ein Merkmal an. Zur menschenlesbarkeit kann es ja drinbleiben, aber technisch fällt es dann raus.

3) "524431 Reinhard, Dobel :Testanschluss " siehe oben
4) "563024 Sebastian, Bad Fuessing :Testplatz " siehe oben
5) "338806 Rudolf, Weissenfels :Zweitanschl." siehe oben

6)767676 "Weather service en (Per) TEST PHASE" hier gibt es den ersten (Test) Dienst welcher nicht in DE verantwortet wird. Warum wird hier nicht das Landeskürzel verwendet. Ist nach Regel 12 allerdings nur mit Ortsangabe erlaubt.

@ Fred

Regeln für die Benennung:
Wenn von 5 Parametern 4 optional sind, bin ich mehr als echt verwundert. Ich wünsche mir nach wie vor den Ort als Pflichtfeld unabhängig vom Landeskürzel. Dieser ist sowieso fast überall dabei, ausser bei Diensten. Dort nur manchmal den (Namen) zu lesen wird bei zunehmender Namensgleichheit auch nichtssagender. Zudem ist der Ort des Hostings ja durchaus bei Problemen interessant.
Zitat:
"12. Eine Länderangabe ist nur in Verbindung mit einer Ortsangabe erlaubt"
Zitatende
Ich kann mir den Grund vorstellen aber toll ist das nicht. Damit wäre ein Dienst ohne Ort (siehe oben) nicht direkt (auch menschenlesbar) als "ausländich" erkennbar. Bei Ort als Pflichtfeld entfällt dieses Problem

Zitat:
"Größtenteils" kann ich nicht nachvollziehen. Der Teil mit der Erkennung zweier Ziffern im Maschinentyp vielleicht."
Zitatende
Ich schon, der extrem zielgerichtete Code bestand zu 70% aus der Erkennung der NummernZiffern in allen Kombinationen, trotz der Funktion re, die dem RegEx entspricht. Der Rest war u.a. eine Suchschleife, die jetzt mit den eindeutigen Trennern durch direkt zugreifende Stringfunktionen ersetzt werden kann.

Gruß
Willi

[TheRaph]

Hallo zusammen,

Dein Bemühen in allen Ehren, aber wenn Du eine selbsgenerierte Inputliste mit deiner eigenen Auswertung testest, muss das ja funktionieren.
Die Zeile "122267 Anders, Turku (FI) Testplatz Fehler" sehe ich daher als gewollten Negativtest an.

OK, ich übernehme die volle Verantwortung und trete von allen meinen nicht-vorhandenen Ämtern zurück.

Im Ernst: Das war nicht anders zu erwarten. Ich habe in der Gesamten Liste erst mit den von Willi und Fred genannten Algorithmen durchlaufen lassen und daraus die Korrigierten Zeilen erstellen lassen. Dann habe ich alles per Hand kontrolliert und Doppelpunkte bei nicht erkannten FS gesetzt usw. erst dann ist der Check gegen den RegEx gelaufen.
Edit: Der Datensatz 122267 konnte vom Automaten nicht erkannt werden und ist bei der Handarbeit durch die Lappen gegangen.
Richtig wäre „Anders, Turku (FI) :Testplatz“, dann würde auch der RegEx zuschlagen.

Gibt noch 2 für die das gilt:

Code: Alles auswählen

185855 	Petr, Praha (CZ) HOME :T1000            	28	Fehler
831831 	Petr, Praha (CZ) OFFICE :T1200SD        	32	Fehler 

Wie beim Fall oben ist der Doppelpunkt falsch, weil da noch eine „Zusätzliche Information zum FS“ drin ist, die ... aber diskussion weiter unten.

Sollten heißen:

Code: Alles auswählen

Petr, Praha (CZ) :HOME T1000
Petr, Praha (CZ) :OFFICE T1200SD

Beim Check gegen den RegEx habe ich nur kontrolliert ob er matchet (und das offensichtlich nicht mal gründlich) und einmal grob drüber geschaut. Da war Nachts 2:00 nicht mehr drin. Die Jugend von heute ist eben nicht mehr belastbar.
Zumal keiner weiß, ob diese Notation den Zuschlag erhält. Wenn es alles Abgesegnet ist, geht’s auf Fehlersuche.

Die Beispiellisten mit KLKL zu benamen, hat mich verwirrt, da dieser Begriff hier noch nie benutzt wurde.

Da hoffe ich auf Welpenschutz und wohlwollende Vergebung in meine Richtung. Ich dachte das beides sei das gleiche. Kommt nicht wieder vor.

Frage: Wenn das hier die Teilnehmerliste ist, wo bekomme ich dann die KLKL her?

In der Inputliste sind mir aber einige Punkte aufgefallen, die eingabetechnischer Natur sind und von Dir so übernommen oder deklariert wurden.
1) "952532","MAKERFAIRE HANNOVER 2016","5","","77.21.126.119","134","" wurde zu : 952532 MAKERFAIRE HANNOVER :2016
folgerichtig ist der Maschinentyp jetzt 2016. Als Ursprungsangabe sollte lieber " MAKERFAIRE2016 , HANNOVER "stehen und alles wäre richtig.

Jo der 2016 hat mehr als 2 Ziffern und wurde deshalb im automatischen Durchlauf als FS erkannt. ... Der Doppelpunkt kann weg, dann ist es ein Name. Oder man macht es wie du vorgeschlagen hast.

2)"16367","Micha, Beelitz offline","5","","87.187.157.239","134","" wurde zu : 16367 Micha, Beelitz :offline ob das wirklich als Maschinentyp zu bezeichnen ist, ist fraglich. Für so etwas bietet sich doch ein Merkmal an. Zur menschenlesbarkeit kann es ja drinbleiben, aber technisch fällt es dann raus.

3) "524431 Reinhard, Dobel :Testanschluss " siehe oben
4) "563024 Sebastian, Bad Fuessing :Testplatz " siehe oben
5) "338806 Rudolf, Weissenfels :Zweitanschl." siehe oben

Vor der Frage habe ich auch gestanden. Wir haben kein weiteres Datenfeld frei.
Auf die Schnelle habe ich das Datenfeld „Fernschreibertyp“ mal als „Informationen zum Fernschreiber“ interpretiert.
Deshalb auch Regel 9 mit „alles Erlaubt“

Hier bleiben 6 Möglichkeiten das zu lösen:
1. Wir lassen es als „Informationen zum Fernschreiber“ und die Infos bleiben Menschenlesbar drin
2. Wir schmeißen die Info Raus
3. wir erstellen für gewisse Sachen zusätzliche Merkmalskenner (z.b. offline)
4. wir schieben die Info zum Namen
5. wir kreieren ein eigenes Sonderzeichen für Nicht-FSTyp-Informationen (z.B. ?)
6. jemand hat eine bessere Idee

Ich favorisiere 1. und 6. alles andere finde ich doof.

6)767676 "Weather service en (Per) TEST PHASE" hier gibt es den ersten (Test) Dienst welcher nicht in DE verantwortet wird. Warum wird hier nicht das Landeskürzel verwendet. Ist nach Regel 12 allerdings nur mit Ortsangabe erlaubt.

@ Fred

Regeln für die Benennung:
Wenn von 5 Parametern 4 optional sind, bin ich mehr als echt verwundert. Ich wünsche mir nach wie vor den Ort als Pflichtfeld unabhängig vom Landeskürzel. Dieser ist sowieso fast überall dabei, ausser bei Diensten. Dort nur manchmal den (Namen) zu lesen wird bei zunehmender Namensgleichheit auch nichtssagender. Zudem ist der Ort des Hostings ja durchaus bei Problemen interessant.
Zitat:
"12. Eine Länderangabe ist nur in Verbindung mit einer Ortsangabe erlaubt"
Zitatende
Ich kann mir den Grund vorstellen aber toll ist das nicht. Damit wäre ein Dienst ohne Ort (siehe oben) nicht direkt (auch menschenlesbar) als "ausländich" erkennbar. Bei Ort als Pflichtfeld entfällt dieses Problem

12. Eine Länderangabe ist nur in Verbindung mit einer Ortsangabe erlaubt

Hier stimme ich Willi in ganzer Linie zu.
Bei echten Menschen sollte der Ortsname Pflicht werden. Edit: Wenn jemand Datenschutzbedenken hat, weil er in einem 3-Häuser-Dorf wohnt, dann könnte dafür der Kreis oder das Bundesland herhalten dürfen.
Bei Diensten macht dies keinen Sinn. (Wen interessiert schon wo die Auskunft wohnt?)

Nach oben vorgeschlagener Syntax kann das Land auch ohne Ort dabei sein, es muss nur ein Komma davor.
Wenn man dann aus „,(US)“ die Klammern extrahiert bleibt eine Leere Menge für den Ort übrig und das „US“ für den Standort.
Regel 6a: Ort ist bei allen menschlichen Personen Pflicht, bei Institutionen ausdrücklich empfohlen und bei Diensten erlaubt.
Dies macht dann Regel 12 überflüssig.

Oder wenn sie doch bleiben soll dann ggf. so?
Regel 12: Eine Länderangabe ist bei Personen nur in Verbindung mit einer Ortsangabe erlaubt.

Edit: Noch folgender Vorschlag:
Regel 13: Eine Länderangabe für einen Dienst sollte auf die Sprache und nicht auf den Standort abgestimmt sein.

@Willi: kann es sein, dass deine Wetterdienste nicht erreichbar sind? Oder liegts an mir.
Habe auch versucht dir die Frage per FS an die 89899 zu stellen, kam aber auch „nc“ vom i-telex zurück. Die „0“ konnte ich anrufen.

Gruß Raph

[FredSonnenrein]

Hallo zusammen,

ich habe jetzt mal Nägel mit Köpfen gemacht und die Einträge auf dem Teilnehmerserver entsprechend der Regeln aus viewtopic.php?p=31856#p31848 aktualisiert.
Es sind sicherlich noch immer "fehlerbehaftete" Einträge vorhanden, ich wollte hiermit zunächst eine "Arbeitsgrundlage" schaffen.
Und wenn nicht massiv Meldungen in der Art "Was ist das für ein Mist?" kommen, bleibt das auch so.

Über das Thema "Benennung der Dienste" habe ich einen eigenen Faden eröffnet: viewtopic.php?t=3793

Ortsangabe ist Pflicht bei "natürlichen Personen": Ja gerne.

Bei Anschlüssen von Museen wird es schon schwieriger: Soll der Eintrag wirklich "Norddeich Radio Museum, Norddeich =oz" heißen?

Thema "Maschinentyp": Ich bin auch dafür, dass dieses Feld den Maschinentyp enthalten KANN, aber auch für andere "Anschlussbeschreibung" verwendet werden kann (z.B. Testanlage o.ä.). Klar ist, dass "offline" woanders hin gehört. "Offline" ist übrigens schon seit einiger Zeit als "Port = 0" charakterisiert (und wird beim i-Telex auch entsprechend behandelt --> "abs").

Nachtrag: "Formfehler" in den jetzt vorhandenen Einträgen bitte per PN an mich. Der Faden hier muss nicht noch weiter aufgeblasen werden.

Viele Grüße,

Fred

[TheRaph]

Hallo zusammen,

ich habe jetzt mal Nägel mit Köpfen gemacht und die Einträge auf dem Teilnehmerserver entsprechend der Regeln aus viewtopic.php?p=31856#p31848 aktualisiert.
Es sind sicherlich noch immer "fehlerbehaftete" Einträge vorhanden, ich wollte hiermit zunächst eine "Arbeitsgrundlage" schaffen.
Und wenn nicht massiv Meldungen in der Art "Was ist das für ein Mist?" kommen, bleibt das auch so.

Hier schon mal 2 weitere zum Berichtigen:

Code: Alles auswählen

185855 	Petr, Praha (CZ) HOME :T1000            	-->Petr, Praha (CZ) :HOME T1000
831831 	Petr, Praha (CZ) OFFICE :T1200SD        	-->Petr, Praha (CZ) :OFFICE T1200SD

Über das Thema "Benennung der Dienste" werde ich einen eigenen Faden eröffnen.

Verlinkst du den dann hier?
Und Von wegen „Anschlusstyp“ ist die Liste final?

z: nur Zeitweise (heißt: Nur am Wochenende oder ähnlich, bei nächtlicher Abschaltung ist dieses Attribut unpassend).
w: regelmäßig wechselnde Maschinen angeschlossen (z.B. Hauptnummer wandert durch die Nst. - gilt nicht bei gelegentlicher Rufumleitung)
s: Streifenschreiber
a: Dienst (also nicht als Nachrichten-Ziel geeignet)
o: öffentlich z.B. Museen oder Ausstellungen
t: Testanschluss (Nachrichten werden typischerweise nicht gelesen, auch Geräte ohne KG möglich)
u: für Maschine mit US-TTY Zeichensatz
k: für Maschine mit 3. Ebene Kyrillisch (oder andere - vorher fragen)
b: bedarf, FS muss vorher fernmündlich (oder Forum etc.) angekündigt werden
x: Gerät hat keinen KG

Bei Anschlüssen von Museen wird es schon schwieriger: Soll der Eintrag wirklich "Norddeich Radio Museum, Norddeich =oz" heißen?

Nein, deshalb ja auch „Ort bei Institutionen empfohlen“ nicht „Pflicht“...
"Norddeich Radio Museum =oz" reicht vollkommen.

Raph

[detlef]

t: Testanschluss (Nachrichten werden typischerweise nicht gelesen, auch Geräte ohne KG möglich)
x: Gerät hat keinen KG

Kein KG ist immer möglich. Ich muss hier immer mal einhaken, damit nicht durch die Hintertür eine KG-Pflicht eingeführt wird.
Es kann ja auch jederzeit auf einen FS ohne KG umgeleitet sein. Auf einen KG kann man sich generell nicht verlassen und wüsste auch nicht, was man davon abhängig machen sollte ob ein KG vorhanden ist.