What should library container usage keys look like?

[kdmccormick]

Library blocks follow the key schema:

lb:ORG:LIB:TYPE:SLUG

e.g.,

lb:axim:Lib1:problem:abc

Should library containers follow this? e.g.,

lb:axim:Lib1:unit:xyz

Or should they have a completely new key type? e.g.,

lc:axim:Lib1:unit:xyz  # lc:ORG:LIB:TYPE:SLUG

lc:axim:Lib1:xyz  # lc:ORG:LIB:SLUG (type info excluded)

[kdmccormick]

Do we forsee a case where a container of kind X wants to turn into container of type Y without changing its identity?

e.g., a Sequence which becomes a SplitTest halfway through the run of the course.

[kdmccormick]

@ormsbee @bradenmacdonald :

As I review #278, I am finding myself thinking about LC content along these lines of this taxonomy:

• A PublishableEntity is the evolution of the original all-encompassing XBlock idea. Two major kinds of PEs are:
  • Component, the evolution of the "leaf XBlock", which can be further specialized as:
    • Video
    • Problem
    • etc
  • Container, the evolution of "structural XBlocks", which can be further specialized as:
    • Unit
    • Sequence
    • etc

I know that's a very simplified view of LC, but we need to be mindful that most developers will have a simplified mental model of LC until they really need to dive into it.

All that's to say: I'm seeing "Components" and "Containers" as two distinct taxa of content, each containg sub-types of content. It would make a lot of sense to me, therefore, for components to occupy one key namespace (lb:) and containers to occupy another (lc:, ls:, whatever)

(cc @mariajgrimaldi , just in case this thread interests you)

[bradenmacdonald]

@kdmccormick Yes, that makes sense to me.

[bradenmacdonald]

Just noting that lc: is a bit ambiguous as to whether the C means "component" or "container", so ls for library structure may make more sense; but we're also not using the term "structure" anywhere else.

[ChrisChV]

@bradenmacdonald @kdmccormick

Just noting that lc: is a bit ambiguous as to whether the C means "component" or "container", so ls for library structure may make more sense; but we're also not using the term "structure" anywhere else

I think both have problems.
Keys for collections use lib-collection:. To avoid ambiguities, I think we can use lib-container:, what do you think?

[bradenmacdonald]

@ChrisChV I guess lib-container: is fine by me, but once we get to courses I wouldn't want to use something like that because I think it's too long.

[ChrisChV]

I've been thinking about other alternatives:

• lct: (It's the one I like the most now.)
• lib-cont:
• lib-ct:

[bradenmacdonald]

I like lct: :)

[kdmccormick]

+1 for lct:

[kdmccormick]

See openedx/opaque-keys#369 for implementation