Document semantics of the import

[FredrikWendt]

In this repo, there's documentation of the schema, its data types etc, but I can't find any documentation on the semantics of the import process. I'm looking for answers to questions like:

• what happens if we present an empty document (no provider section)? Will all our data, accounts and course information be deleted?
• am I right in assuming that we need to provide elements/data for everything we want present in your system? (Anything we enter manually using web admin interface, will be replaced when the import has completed.)

[Kralizek]

Hi @FredrikWendt,

Thank you for your questions and it's nice to get feedback on the documentation we offer on this repository.

Our intent is to provide as much documentation as possible without overloading the implementer with unnecessary details. As usual, the line between necessary and unnecessary is thin and easy to miss.

About your questions...

When using EMG XML 2.0 and 3.0, our system uses the specified institute/provider identifier to understand which institute/provider needs to be updated. if the document is totally empty, no institute/provider is found and none can therefore be updated.

On the other hand, when an institute/provider is found, we make sure to import all the information into our systems. Usually, we try to be very conservative and only hide or soft-delete entities that were previously imported and have now disappeared from the feed.

Also, please note that some information might be imported the first time and ignored in subsequent imports (content fields are the most prominent example so that our premium SEO-friendly content is not overridden).

As for the risk of a customer overriding the content via the web interface we offer them, it depends a lot on whether or not they create a new course/education or they edit one that has been previously imported as we use the uniqueIdentifier field to match entities in the feed with those existing in our database.

[FredrikWendt]

This life cycle of data would be great to have documented somewhere.

In our case, everything was setup manually, and we are now looking to add dates for courses, and in some rare cases have them removed. In general, we don't update our descriptive texts that often (except for promoting the actual instructors), so it's interesting to learn the semantics of the elements.

[FredrikWendt]

As a general comment, if there's a more RESTful API we could integrate towards (PUT & POST (create and replace), PATCH (partially update), DELETE, on clearly defined resources/URLs, does bring semantic meanings and allows for less processing as it enables push rather than pull), we'd love to build/try out that instead of the current approach. :-)

(We don't mind XML Schemas any bit, just that the "we fetch some XML" doesn't tell us how that's processed, or when.)