Structure of (non)personal contacts

[kaiqu]

Continuing the discussion in (the now closed) erasmus-without-paper/ewp-specs-api-institutions#8:

I think personal and non-personal contacts should be structurally different

You may be right. This is one of the issues I have delayed on purpose, because I'm still thinking about it. On one hand, clients might simply display all the contacts to the viewer (in this case, having one abstract contact "view" might be enough). On the other hand, other clients might want to store them to their databases (in this case, we need more precise structure). We will come back to this.

Ok. Maybe an attribute could differentiate?

It depends. If it turns out that this information has to be stored by the client in an actual PERSON table, then attribute might not be enough (we might need separate first name and last name fields).

This also touches another discussion we had about fact sheets, where the conclusion was that they should always be PDF URLs, to avoid security problems. Doesn't this apply to (at least non-personal) contacts as well, @wrygiel ?

[wrygiel]

This also touches another discussion we had about fact sheets, where the conclusion was that they should always be PDF URLs, to avoid security problems. Doesn't this apply to (at least non-personal) contacts as well, @wrygiel ?

It doesn't. Security issues we talked about in fact-sheets were related to displaying foreign (and possibly malicious) HTML in local web pages. The <contact> element does not allow HTML in any of the fields, so there are no such concerns here.

[kaiqu]

Ok. But are you any closer to concluding on the structure of non-personal contacts?
As it is, they are not included in the model.

[wrygiel]

But are you any closer to concluding on the structure of non-personal contacts?

You mean "how certain am I that XSDs won't change"?

[kaiqu]

But are you any closer to concluding on the structure of non-personal contacts?

You mean "how certain am I that XSDs won't change"?

No, I mean "do you have a suggestion or tentative conclusion"?

[wrygiel]

I'm not sure if I understand your question, but currently the XSDs use abstract contacts only. I'm quite certain that we need both personal and non-personal ones in the model, but both of them are currently represented using the same abstract view in XSD.

Of course, we can add more fields to this abstract view, allowing the reader to easily detect programmatically if the contact is personal or not - is this what you're missing?

[kaiqu]

After some thought, I have renamed the Coordinator entity to Contact/Fact Sheet, and generalized it to include both personal and non-personal contacts, as well as fact sheet information. I think this solves the problem, and it also obviates all the Address and URL attributes that have been cluttering up the diagram.
Posting a new version of the model soon...