Open ghost opened 10 years ago
Thanks for the report. It does look like JQTI+ is a bit out of sync with the information model here, so it's something I'll need to look into fixing.
(There ended up being quite a few changes to the content model while QTI 2.1 was getting finalised, so this is probably not the only bug of this type! See also issue #50.)
simpleBlock (http://www.imsglobal.org/question/qtiv2p1/imsqti_infov2p1.html#element10127) : "Contains : block [*] {ordered}"
Object does not inherit from Block, so JQTI+ looks like it fits the information model. Is this really a bug?
I see your point @ccreel but the QTI 2.1 schema XSD allows this relationship (screenshot below from XML Spy). The question I have is why does the XSD allow the relationship I am trying to use, but the JQTI+ content model does not. I'm just trying to understand whether this is a bug with their validation, or if this is a deliberate and proper restriction on the part of JQTI+. Thank you @davemckain for your earlier response!!
By the way, I understand this can all be resolved on my end by just placing the <object>
within a <div>
tag, but I'm trying to add markup only when absolutely necessary. I'm a purist at heart :)
@kobell Object can be a descendant of rubricBlock if it's in the proper context (e.g. wrapped in a div). Rubric Block has a base class (simpleBlock) which has the restriction on what it contains (descendants of block). The reason why the schema "allows" it is because simpleBlock is not part of the Schema. It is abstract and cannot be instantiated, or in terms of XML, used as an element and therefore couldn't be included. It's part of the object model which can be found in the links I posted and in your original post. In JQTI+, TAO and the IMS specification, it all restricts Rubric Block to containing Block elements.
I've had another look at the information model and @ccreel is correct in saying that a rubricBlock cannot contain an object. However, like, @kobell, I'm confused why this is allowed in the schema. (The schema used to roughly mirror the class hierarchy defined in the info model, but later versions of the schema use a flattened model, so it should be easy to exclude object here.)
I'll query this with the maintainers of the schema and get back to you once I hear back.
Thanks you two! Like I said, I respect the model and can add the <div>
s but it would be great to have some consistency between the model and the schema. In this case it feels like you have to wrap the tags "just because". On an unrelated note, we are interested in working on the QTI schema to provide specs for graphing interactions. Do you know how we can be a "part" of the QTI development process? Not so much like a company making suggestions, but actually helping by submitting XML?
@kobell IMS host a public QTI forum, which might be a good place to start. Here's the URL:
http://www.imsglobal.org/community/forum/categories.cfm?catid=52
It's not that busy though, so I guess there's a risk that people aren't reading it that often. There are definitely folk who I think would be very interested in graphing interactions!
I've had a response from Wilbert Kraan, the current editor of the spec:
"In case of doubt, I'd always say that the information model is correct when it clashes with the schema, just because of the level of scrutiny that went into the info model. Having said that, I suspect people sticking objects in rubricBlock is quite likely, whether they're supposed to do that or not. It may be a case of being sloppy on import..."
So it looks like the info model is probably correct, though the restriction on putting objects on rubricBlocks is perhaps something that could be relaxed in future. In the short term, I'm afraid you will have to wrap these in divs if you want to use them with QTIWorks (and anything else based on the original JQTI) library, as JQTI mirrors the info model and can't handle anything that doesn't fit with that model.
Sorry that doesn't help too much!
@kobell One of the QTI experts I know is involved in mathematical assessment, and she's very interested to look into graphing assessment too. Would you like me to put you in contact?
Yes, sir! Sorry for the delay, for some reason, I was not getting notifications that you replied, and I happened to check manually today. Hope you have been well, and thank you for everything so far.
Please have her contact Kevin Campbell (kcampbell [at] kobellsystems.com).
I am running into the following error with QTIWorks.
My XML is as follows:
If I am understanding correctly, according to QTI 2.1,
<rubricBlock>
is a type ofsimpleBlock
whose only restriction is it cannot contain interactions: http://www.imsglobal.org/question/qtiv2p1/imsqti_infov2p1.html#element10252If someone could please guide me in the right direction, or confirm i'm not crazy that would be excellent. Thanks!