consider removing enumerations in folder & file names in architecture/

[capsulecorplab]

It's unclear as to the purpose of enumerating folder and file names in the architecture/, e.g., 3-DataStructures or 3-DataStructures/1-Component.yaml. As one extends the language definition, it can get slightly cumbersome to specify an enumerated data structure, especially when it's under review and unclear whether it should be added or not

[j-simmons-phd]

A couple of thoughts...

• This is probably more of a M30ML spec issue than DOF, we are just seeing it in DOF because it is our primary M30ML project
• I originally made this design decision based on my experience working with SysML containment trees. Similar to the file system, the order of content can only be controlled through naming conventions (like prefix numbering). And I have found without controlling the order of content, it can be difficult to get to the content you want as folders and files jump around whenever new content is added and everything is resorted by name

So, what other ways could we control the order of content presentation??

[capsulecorplab]

I see. Though, the issue is more concerning whether and where it's needed. I think the idea of controlling order of content makes sense for folders, as it seems to echo a sort of traceability pattern (i.e., references beget stakeholder needs -> user stories -> data structures). I'm not sure if the same can be said for file names within a folder.

[capsulecorplab]

Another concern is if removing a file in the enumerated case, would the other file names be renamed or remain the same?

[capsulecorplab]

As for how to control ordering of content. That could be done on the presentation/view layer of the architecture (i.e., the static site page) where the template iterates through the element id's within a particular folder

[j-simmons-phd]

Those are all great points, and are exactly my frustration with SysML containment trees as well. My preference is to have a single consistent solution for managing order in views for both folders and files as a means of avoiding extra complexity. Besides, once we have a solution for files, it should just work for folders as they are essentially the same thing in the filesystem.

So, what if we add a dot file to DOF folders that contains a yaml list (that is all) of file/folder names within the current folder specifying their presentation order? Views could then consult this list for the order of presentation. If not present, the views default to alpha order (so all of our current structures would work while we transition to them to the new implementation). The file would be very simple, something like

- xyz.yaml
- abc\
- foo.yaml
- bar.yaml`

This would add a little overhead to manage that file, while eliminating any need for numbers in pathing and it would easily fit into our current nested structure approach.

What do you think?

[m30-css]

This makes me think of how helm does it for Kubernetes. Helm is a tool that renders templates for the yaml files that describe the resources you want in Kubernetes, and then has some knowledge about what the best order to apply them is. For example, it knows to apply config maps before deployments because deployments can use config maps (not because the deployments necessarily use the config map). Then when it comes to custom resources, those generally are just applied at the end, IIRC.

Similarly, m30ml could have that knowledge baked in. Another tool could use a different approach.

[m30-css]

This might be what your talking about @j-simmons-phd or just similar, is to have a file at the top level that defines the ordering rules