You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 28, 2020. It is now read-only.
As a course author, I would like a way to preserve the metadata I've added to a learning resource: when it's exported form LORE, imported into edX and re-exported and re-imported into LORE. In particular, I don't want to have to re-enter metadata on the same learning resource, and I'd like to avoid creating duplicate learning resources.
We've discussed a couple of different ways this could be done:
XML attributes:
Looks nice
relatively easy to parse when necessary
Since OLX doesn't have a schema, we can add arbitrary attributes
we need to test what happens with edX on import and export
XML comments:
allows for more arbitrary structure
we need to test what happens with edX on import and export
edX Asides (an experimental extension to XBlock:
intended to support tagging of XBlocks, which seems similar to what we're doing
not yet in production
no serialization established yet.
Another question to consider is whether we want to embed all of the learning object's metadata in the OLX export, or just an GUID that can be used to look up the metadata.
The text was updated successfully, but these errors were encountered:
The elephant in the room with these proposals is that edX (the elephant) will change position without warning, putting our expensive designer furniture (the room) at risk.
Is there any practical way that we can get edX buy-in on our plan of choice?
I propose the easiest path for collaboration is using OLX and pursuading edX that OLX is a viable path to interoperability.
@Ferdial and I hard a brief conversation with Dave Ormsbee and Joel Barciauskas today about unique identifiers in OLX.
Dave said that it's a part of the XBlock architecture to "ignore anything that it doesn't understands." This should mean that edX will import and export any (tags and attributes?) in the OLX that are unfamiliar.
He did want to talk more, to make sure we didn't have any namespace collisions, and they were also interested in the scope of what we're interested in.
So, there's hope that the elephant won't step on us -- because it ignores the furniture anyway.
The elephant in the room with these proposals is that edX (the elephant) will change position without warning, putting our expensive designer furniture (the room) at risk.
Is there any practical way that we can get edX buy-in on our plan of choice?
I propose the easiest path for collaboration is using OLX and pursuading edX that OLX is a viable path to interoperability.
—
Reply to this email directly or view it on GitHub #880 (comment).
Dave said that it's a part of the XBlock architecture to "ignore anything that it doesn't understands."
We don't really want it to "ignore" what it doesn't understand, we want them to preserve what it doesn't understand. The difference is inaction versus action. "Preservation" is an action; "ignoring" sounds more careless.
As a course author, I would like a way to preserve the metadata I've added to a learning resource: when it's exported form LORE, imported into edX and re-exported and re-imported into LORE. In particular, I don't want to have to re-enter metadata on the same learning resource, and I'd like to avoid creating duplicate learning resources.
We've discussed a couple of different ways this could be done:
Another question to consider is whether we want to embed all of the learning object's metadata in the OLX export, or just an GUID that can be used to look up the metadata.
The text was updated successfully, but these errors were encountered: