Comments (7)
Hello Birgit,
I just made a proposal in a new branch. Can you have a look and give me feedback?
from id.
Small comment wrt Readme.md in this new branch.: Revision 2.0.1 from 2019 [3] should be Revision 2.0.1 from May 2020 [3]
from id.
When I am reflecting on this again it might be better to not have folder for the different parts: in the moment we merged part 2 and part 3 and it can be expected that part 1 might be splitted in the future. So perhaps instead we should make more generic folders like "informationModel" "Interfaces" etc. without version: the versions should only be contained in the ids themselves.
E.g. vdi/2770/1/0/Document means Element Document in VDI 2770 Version 1.0 whereas vdi/2770/Document/1/0 means Element Document V1.0 in VDI 2770
What do you think?
Could there be more than one id for the same element? How do we document obsolete elements and thus obsolete ids?
from id.
Trying to catch up on this topic.
E.g. vdi/2770/1/0/Document means Element Document in VDI 2770 Version 1.0 whereas vdi/2770/Document/1/0 means Element Document V1.0 in VDI 2770
That's a very valid point, the first version/revision paths (should) link to the versioning of the source document. I am trying to sort my thoughts a bit:
Pattern 1: vdi/2770/1/0/Document
- Versioning of the entities is bound to the versioning of the source standard.
- No revisions possible if the source version has not been changed.
- Bugfixes are independent, I would accept them at all times without having bugfix versions explicitly in the URIs
Pattern 2: vdi/2770/Document/1/0
- Problem with different versions of the source: In case version 2.0 of VDI2770 drops the
Document
element, the pathvdi/2770/Document
still stays. - changes to the
vdi/2770/Document
element in this repo can be tracked (vdi/2770/Document/1/0
,vdi/2770/Document/1/1
and so on)
Pattern 3: vdi/2770/1/0/Document/1/0
- Contains both a versioning for the source standard as well as the entity in this repo
- Bit of an overkill to me, creating certainly a lot of confusion and misunderstandings
--> For the existing aas, I'd prefer to leave the scheme as it is (Pattern 1). Just to prevent breaks as those URLs are also used in the RDF serialization. However, Part 2 already uses the scheme https://admin-shell.io/aas/API/<element-name>/1/0/RC02
(Pattern 2), which gives us only two options (or am I missing another one?):
Option 1: We introduce Pattern 2 for the Part 1 classes too, including changing the already existing versions.
Option 2: We change the identifiers in Part 2 for the final release 1.0.
What's your opinion?
from id.
Could there be more than one id for the same element?
I would say so in general, yes. But simply because we cannot enforce it globally. The convention should be to not create additional identifiers, and definitely not in this repository.
from id.
How do we document obsolete elements and thus obsolete ids?
Difficult question. I would say they should be marked with a deprecated
tag in the latest version before the deletion, and then simply omitted...
from id.
Small comment wrt Readme.md in this new branch.: Revision 2.0.1 from 2019 [3] should be Revision 2.0.1 from May 2020 [3]
I have integrated your comment with #22 and merged now.
from id.
Related Issues (11)
- DataSpecificationTemplate for Physical Units missing HOT 1
- Link to Readme.md Template wrong HOT 3
- Link to Template in Readme.md invalid HOT 2
- add relationship concept "CapabilityRealizedBy" HOT 1
- Repository Description is missing HOT 4
- AAS API (Part 2) Elements are missing HOT 1
- Generation of id and link to CD repo's not well supported / Improvement Idea -> Wikibase HOT 2
- Test HOT 2
- Issue #1 of Example PR HOT 1
- Licence HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from id.