FIRST

I can see the values being save to the QTI XML on the file system - so it must just be a [re] display issue.
Perhaps in the parsing of the XML?
---- partial XML example ---------

<qti:questestinterop xmlns:qti="http://www.imsglobal.org/xsd/ims_qtiasiv1p2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/ims_qtiasiv1p2 ims_qtiasiv1p2.xsd"><assessment ident=" "><section ident=" "><item ident="leinfelder.1292.3" title="QuestionTypeMultiple choice"> <itemmetadata> <qtimetadata> <vocabulary uri=" " vocab_type="text/xml">bloom</vocabulary>
<qtimetadatafield> <qti:fieldlabel>Concept</qti:fieldlabel>
<qti:fieldentry>Psychomotor</qti:fieldentry>
</qtimetadatafield>
</qtimetadata>
</itemmetadata>

Looking at the code for parseDOMNodeAsResponseItem in MultipleChoiceResponseItem, I don't see any code looking for the meta data.

I do see a method called parseDOMNodeAsMetadata in the abstract ResponseItem class. So I think this will be as simple as actually making a call to that method in the various ResponseItem subclasses.

Sandeep, can you give this a look?

On Ryan's suggestion, I included a call to parseDOMNodeAsMetadata() from within
a response item type, specifically, in MultipleChoiceResponseItem.java's
parseDOMNodeAsResponseItem() function.

1)
The following line of code from parseDOMNodeAsMetadata() in ResponseItem.java

NodeList metadatas = XMLUtilities.getNodeListWithXPath(root,"./qtimetadata");

does not seem to extract the <qtimetadata> items from the XML file corresponding
to assessment items that I created! I even tried making the lookup based on
"./itemmetadata/qtimetadata" but with no success.

2)
On further probing, I found an interesting comment line in question.java that
goes as follows:

question.java: header for parseXML()

/** * Note: This method may erase existing atrributes and ResponseItems * even if parse fails. * Other Note: Does not parse Metadata. Additional code will need writing * if this is wanted.

I am not sure if the above comment still holds good.

3)
Next, I tried to look into the code that helps a user add categories
explicitly at the first place, which got me to

- AddCategoryAction (relevant code!)

if(ri.addMetadataItem(CategoryComponent.KEY,newVItem))
   {
        MainWindow.getInstance().getUndoMediator().addEdit(new AddCategoryUndoableEdit(ri,newVItem));
       }

From the above code, I wondered why there isn't an equivalent code for
adding categories to a response item object when the parser is using an
existing data package to construct the question list from?

4)
Then there is a line: Node rootNode = adp.getMetadataNode();
in dataPackages2QuestionList() under AssessmentItemUtil.java
The variable rootNode is used in the following command to generate
"root", which is used in parseXML function of question.java and hence relevant.

node = XMLUtilities.getNodeWithXPath(rootNode, "//assessment/section/item");
q.parseXML(node, questionNumber); // node is referred to as root

Currently, I am a bit unsure as to what will resolve the issue!
Any suggestions?

See my commit message for the modifications that I made. I believe this has solved the problem. Sandeep, I'd like for you to do some more testing if you don't mind; I only tested with a single case, which had one Bloom item attached to it, but it does work now.

The code that generates category metadata appends a qti: namespace prefix. None of the other items in the generated XML have a namespace prefix.

Ben, I'm not that good with XML namespaces, but I suspect that because the root element of a question file has a qti prefix (qti:questestinterop), all of its descendants will inherit its namespace and the qti: in front of the fieldlabel element is unnecessary. What does putting the qti: in front of it actually do? Is it making the name of the element actually include a qti:?

Ryan, as far as the qti: namespace prefix is concerned...I'm not sure why it is required. I've done some sample document validation with these fields and the parsers definitely want there to be the prefixes. The only thing that I can see that is different about those tags is that they are not complex types (just xs:string) in the schema. I think you have to include them at this point in the game

(In reply to comment #5)

Ryan, as far as the qti: namespace prefix is concerned...I'm not sure why it is
required. I've done some sample document validation with these fields and the
parsers definitely want there to be the prefixes. The only thing that I can see
that is different about those tags is that they are not complex types (just
xs:string) in the schema. I think you have to include them at this point in the
game

OK, I'll go ahead and assume that this needs to be both written and included in the XPath to read in the meta data. Sandeep, if you can do a bit more testing, I think we can call this bug fixed.

Multiple metadata associated with an assessment as well as individual items in the
assessment are preserved across multiple attempts to open an assessment and edit/view its contents and save it.

Original Bugzilla ID was 4352