add regex to get componentID from control mapping

[aitchkhan]

add componentID from excel in generated implementation

[anweiss]

@aitchkhan @haroonKhan-10p let's try to avoid hardcoding slice indices and instead use range to retrieve the item in question. It's an odd way of iterating.

[aitchkhan]

which slice indices are you referring to?
the one generating the componentDefiniton or the one consuming the index of excel sheet for extracting identifier of UCP?

[asadullah-yousuf-10p]

which slice indices are you referring to?
the one generating the componentDefiniton or the one consuming the index of excel sheet for extracting identifier of UCP?

@anweiss

[anweiss]

@aitchkhan @haroonKhan-10p @asadullah-yousuf-10p I'm referring to all of them lol. Remember, the CSV that we're using is temporary, at least until the OSCAL "implementation" schema has been fully developed. And even though we have control over the layout of our CSV and can make some guarantees as to the indices of the elements in the slices, other consumers of oscalkit won't have this knowledge. Furthermore, it's simply not really an idiomatic way of iterating through slices; especially in this case where we have multi-dimensional slices and our CSV is still changing. Easy to overlook an index and end up with an index out of range error.

[anweiss]

@haroonKhan-10p if you could fix the iteration constructs by removing the hardcoded indices, we can go ahead and get this merged. thanks

[aitchkhan]

@anweiss the componentdefinition iteration index? Because the CSV indices used are identifier for different things like uuids, narratives.

…

On Wed, Jan 23, 2019, 7:58 PM Andrew Weiss ***@***.*** wrote: @haroonKhan-10p <https://github.com/haroonKhan-10p> if you could fix the iteration constructs by removing the hardcoded indices, we can go ahead and get this merged. thanks — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#51 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AINS40vsWVOp7FvpCw6yZVc_uScEgZRnks5vGHihgaJpZM4aFAn2> .

[mohuk]

I believe indices were placed to get things rolling. A future proof solution would not be relying on the csv or google/excel sheets, instead it should be a xml schema listing down the controls and other data in a structured format. Same schema can then be handed over to consumers so they can create their own implementation and import it via oscalkit.

So for Amberjack, can we stick to what we have and add the xml part to the backlog ?

[anweiss]

@mohuk @aitchkhan we can leave the hardcoded indices for now. Please rebase and resolve conflicts and I'll go ahead and merge. I'll create a separate issue for us to address this in the future when the OSCAL "implementation" model matures.

[anweiss]

@aitchkhan @haroonKhan-10p please resolve conflicts and rebase.

[haroonKhan-10p]

updated.

[anweiss]

LGTM

Changes have been addressed.