search

buildingSMART / IFC4.4.x-development

Development of IFC 4.4
Other
8 stars 6 forks source link

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

Open Moult opened 2 years ago

Moult commented 2 years ago

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.

2022-03-03-210052_1338x825_scrot

aothms commented 2 years ago

+1 out of scope and out of date

Moult commented 2 years ago

@aothms any preference for option 1 or option 2?

aothms commented 2 years ago

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

berlotti commented 2 years ago

Like to hear the opinion of @grandfr

Moult commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

grandfr commented 2 years ago

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

Moult commented 2 years ago

@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 commented 2 years ago

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