<commit_before>CrossJobPoster
==============

Status
------

pre-alpha

Overview
--------

PHP implementation of various interfaces to post job offers to jobportals like careerbuilder, monster or FAZjob.NET

References


* [hr-xml.org](http://hr-xml.org "HR-XML")
* [Dokumentation Career](http://dpi.careerbuilder.com/Site/Index.aspx "Careerbuilder Specs")
* [Dokumentation Monster](http://doc.monster.com/ "Monster Specs")
* FAZjob.NET - to be written

Component Requirements, Constraints, and Acceptance Criteria
------------------------------------------------------------
zu berücksichtigen:

        es gibt sehr unterschiedliche Formen von Übertragungswegen: Soap, Mails, FTP
        die Übertragungsprotokolle können auch sehr unterschiedlich sein: XML, HRXML in verschiedenen Versionen, CSV
        ein Übertragungsweg kann mehrstufig sein, zB ein neuer Job bei Career wird in eine Bearbeitungsqueue gesetzt, ist die Bearbeitung erfolgreich, wird zeitlich versetzt ein Success-Status zurückgegeben.
        Sofort zurückgegeben wird nur ein Bearbeitungsstatus 'inQueue' und eine Bearbeitungsnummer
        einzelne Schnittstellen bieten (werden vermutlich) sehr unterschiedliche Vorgehensweisen für eine ähnliche Aufgabe anbieten
        viele Protokolle halten sich grob an einen Standart, aber unterscheiden sich in Details und in der Notwendigkeit der Daten (pflicht, optional, nicht verwendet).
        manche Daten haben eine schnittstellenbezogene Kodierung (zB Career für Abitur=DR3211), diese Kodierung kann abhängig sein von den Ländern.


Das Program soll können:

        Unterschiedliche Übertragungswege realisieren
        Mehrstufige Prozesse beherrschen
        Unterschiedliche Protokolle
        offenes Datensystem, d.h. es können beliebig spezielle Daten hinzugeschrieben werden, verwendet werden sollen jedoch nur die Daten, die für die jeweilige Schnittstelle notwendig sind
        schnittstellenspezifische Datendarstellung (zB für Abitur für Career oder Monster)

Dependencies on Other Framework Components

        Zend_Soap_Client

    Theory of Operation

Die Operationen lassen sich auf drei Ebenen aufteilen

        Anwendung - hier werden die verschiedenen Protokolle der Schnittstelle umgesetzt
        Daten - hier werden die spezifischen Datenstrukturen umgesetzt
        Datengewinnung - eine Schnittstelle zu der Datengewinnung der Anwendung


Es soll eine Basis-Struktur für Daten und für Datenoperationen geben.
Grundsätzlich ist davon auszugehen, daß alle Informationen für alle Schnittstellen sich in dieser Struktur bis in eine gewisse Auflösung unterbringen lassen.
So wird es zB immer Kontaktinformationen zu einer Firma geben, und da wird es fast immer einen Ansprechpartner mit Telefonnummer geben.
Es werden aber auch einige Informationen spezifisch für eine Schnittstelle sein, zB Anfahrtsweg (nicht bei Monster aber bei Career) oder die Sichtbarkeit von Angaben (bei Monster aber nicht bei Career).
Diese Struktur entspricht einem Baum - ist wichtig weil nur so kann sie als XML oder serialize abgespeichert werden, was wiederum ermöglicht, beliebige spezifische Daten einzubinden

Ebenso werden einige Standart-Aufgaben immer wieder auftreten (zB CRUD und Anmeldung/Authentifizierung)
Die Standartaufgaben sollen mit Basisparametern immer laufen, darüber hinaus können schnittstellenspezifische Parameter übergeben werden.
schön wäre hier, daß die Parameter einer Schnittstelle für eine andere Schnittstelle keine Wirkung hätten - so daß die Verwendung von einer Schnittstelle direkt auf eine andere Schnittstelle sich übertragen lässt.
Milestones / Tasks


...
Class Index

Schnittstelle (Export)

    Verbindungsinformationen setzen *<commit_msg>readme.md formatiert<commit_after>### CrossJobPoster

## Status

*pre-alpha*

## Overview

PHP implementation of various interfaces to post job offers to jobportals like careerbuilder, monster or FAZjob.NET

##References


* [hr-xml.org](http://hr-xml.org "HR-XML")
* [Dokumentation Career](http://dpi.careerbuilder.com/Site/Index.aspx "Careerbuilder Specs")
* [Dokumentation Monster](http://doc.monster.com/ "Monster Specs")
* FAZjob.NET - to be written

## Component Requirements, Constraints, and Acceptance Criteria

### zu berücksichtigen:

- es gibt sehr unterschiedliche Formen von Übertragungswegen: Soap, Mails, FTP
- die Übertragungsprotokolle können auch sehr unterschiedlich sein: XML, HRXML in verschiedenen Versionen, CSV
- ein Übertragungsweg kann mehrstufig sein, zB ein neuer Job bei Career wird in eine Bearbeitungsqueue gesetzt, ist die Bearbeitung erfolgreich, wird zeitlich versetzt ein Success-Status zurückgegeben.
- Sofort zurückgegeben wird nur ein Bearbeitungsstatus 'inQueue' und eine Bearbeitungsnummer
- einzelne Schnittstellen bieten (werden vermutlich) sehr unterschiedliche Vorgehensweisen für eine ähnliche Aufgabe anbieten
- viele Protokolle halten sich grob an einen Standart, aber unterscheiden sich in Details und in der Notwendigkeit der Daten (pflicht, optional, nicht verwendet).
- manche Daten haben eine schnittstellenbezogene Kodierung (zB Career für Abitur=DR3211), diese Kodierung kann abhängig sein von den Ländern.

### Das Program soll können:

- Unterschiedliche Übertragungswege realisieren
- Mehrstufige Prozesse beherrschen
- Unterschiedliche Protokolle
- offenes Datensystem, d.h. es können beliebig spezielle Daten hinzugeschrieben werden, verwendet werden sollen jedoch nur die Daten, die für die jeweilige Schnittstelle notwendig sind
- schnittstellenspezifische Datendarstellung (zB für Abitur für Career oder Monster)

### Dependencies on Other Framework Components

- Zend_Soap_Client

### Theory of Operation

Die Operationen lassen sich auf drei Ebenen aufteilen

- Anwendung - hier werden die verschiedenen Protokolle der Schnittstelle umgesetzt
- Daten - hier werden die spezifischen Datenstrukturen umgesetzt
- Datengewinnung - eine Schnittstelle zu der Datengewinnung der Anwendung


Es soll eine Basis-Struktur für Daten und für Datenoperationen geben.
Grundsätzlich ist davon auszugehen, daß alle Informationen für alle Schnittstellen sich in dieser Struktur bis in eine gewisse Auflösung unterbringen lassen.
So wird es zB immer Kontaktinformationen zu einer Firma geben, und da wird es fast immer einen Ansprechpartner mit Telefonnummer geben.
Es werden aber auch einige Informationen spezifisch für eine Schnittstelle sein, zB Anfahrtsweg (nicht bei Monster aber bei Career) oder die Sichtbarkeit von Angaben (bei Monster aber nicht bei Career).
Diese Struktur entspricht einem Baum - ist wichtig weil nur so kann sie als XML oder serialize abgespeichert werden, was wiederum ermöglicht, beliebige spezifische Daten einzubinden

Ebenso werden einige Standart-Aufgaben immer wieder auftreten (zB CRUD und Anmeldung/Authentifizierung)
Die Standartaufgaben sollen mit Basisparametern immer laufen, darüber hinaus können schnittstellenspezifische Parameter übergeben werden.
schön wäre hier, daß die Parameter einer Schnittstelle für eine andere Schnittstelle keine Wirkung hätten - so daß die Verwendung von einer Schnittstelle direkt auf eine andere Schnittstelle sich übertragen lässt.
Milestones / Tasks


...
Class Index

Schnittstelle (Export)

    Verbindungsinformationen setzen *
{'fraction_non_alphanumeric': 0.051790633608815424, 'fraction_numerical': 0.0011019283746556473, 'mean_word_length': 4.8041566746602715, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 4}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5227378', 'n_tokens_mistral': 2179, 'n_tokens_neox': 2241, 'n_words': 826}