Proposal to delete (or heavily cull) concept Project Library Information

[Moult]

So in case you haven't seen Project Library Information I took a screenshot of it below.

In short, it's 5 sentences and 3 tables that have the ambition to describe a full RESTlike API specification for a model server. Crazy right?

It's a bit last minute but I think it's important - I do not think this is in scope for the IFC schema. Maybe as a "model" module for OpenCDE - but not in the schema.

Using IFC library references is a valid way to link an IFC thing to an external system, so yes in the future when such an IFC model server is more standardised, you may use a library association in this manner. However, I do not think it is the responsibility of the IFC schema itself to specify HTTP headers, HTTP verbs, mime types, and so on. It even makes a proposition to link the IfcPerson to the username of the sever (auth system? what? where? how?). It sounds like an "example of what might happen" with enough content to be thought provoking but not enough content to be useful.

There are too many questions that I'd propose:

1. Delete it all. If it actually is a thing in the future, it can return with proper, fully thought-out documentation.
2. At least just cut it down to a few vague sentences about "association with a model server" and delete the portion of the graph to do with the publisher and IfcPerson.

Edit: originally brought up from buildingSMART/IFC4.3.x-development#403.

[aothms]

+1 out of scope and out of date

[Moult]

@aothms any preference for option 1 or option 2?

[aothms]

I hope somebody can fill us in on the history of this thing. Otherwise option 1 :)

[berlotti]

Like to hear the opinion of @grandfr

[Moult]

A note of clarification in case someone stumbles on this issue: I'm not saying IFC should not be used in a model server or revision control server. I'm only saying that right now the documentation that's written about it is not fleshed out at all and should be probably deleted before it misleads anyone, and later in the future when someone does work on this they can republish it either in the spec or outside I don't know but that's a separate issue to be debated.

[TLiebich]

I can't recall how this template made it into IFC spec
in my view a clear +1 for option 1

premature, single-point, implementation method specific - all reasons, why it should best be deleted
(and yes, as @Moult said, this does in no way say, that IFC or associated libraries should not be used in a model server environment - the rest is already said).

[Moult]

Cool if no further feedback (ping @grandfr ) in the next day (we are under such a tight deadline) I'll mark as decided.

[grandfr]

Not 100% sure but I think it is used by the upcoming standards: EN 17549-1 and EN 17549-2

[Moult]

@grandfr how is it being used? If the usage is simply "IFC can be used in a model server" that's OK, this stuff can still be deleted since it isn't fleshed out. If the usage is more specific, perhaps we can review it and improve the current situation?

Do you have access to these standards? I tried searching online and couldn't find a free copy :)

[berlotti]

Seems important for some derivative standards. Let's discuss in detail in 4.4.