Metadata for each item disappears after saving and re-opening
MetaData is tagged using the menu in parser "add category". after it is saved and re-openned the parsed items using the menu " assessment items" under documents menu in parser, the tagged metadata for each items is disappered. it's impossible to check for user of parser if the metadata tagged to items are disappered or just not showing up.
#1 Updated by ben leinfelder almost 10 years ago
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>
#2 Updated by Ryan McFall almost 10 years ago
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?
#3 Updated by Sandeep Namilikonda almost 10 years ago
On Ryan's suggestion, I included a call to parseDOMNodeAsMetadata() from within
a response item type, specifically, in MultipleChoiceResponseItem.java's
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.
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.
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!)
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?
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!
#4 Updated by Ryan McFall almost 10 years ago
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:?
#5 Updated by ben leinfelder almost 10 years ago
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
#6 Updated by Ryan McFall almost 10 years ago
(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
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.