davemckain / qtiworks

**This project will be closed in early 2023!** IMS QTI 2.1 assessment delivery engine and Java development library (JQTI+). Supports the MathAssess extensions. Replacement for QTIEngine/JQTI and MathAssessEngine/JQTI. Note that this project has now ended and no further work is currently planned.
Other
67 stars 55 forks source link

Error: "Illegal child <object> for parent <rubricBlock>" #54

Open ghost opened 9 years ago

ghost commented 9 years ago

I am running into the following error with QTIWorks.

qti-works

My XML is as follows:

<itemBody>
    <rubricBlock use="context" view="candidate author proctor scorer testConstructor tutor">
      <object data="../passages/RSC-76.xml" type="text/xml"/>
    </rubricBlock>
  </itemBody>

If I am understanding correctly, according to QTI 2.1, <rubricBlock> is a type of simpleBlock whose only restriction is it cannot contain interactions: http://www.imsglobal.org/question/qtiv2p1/imsqti_infov2p1.html#element10252

If someone could please guide me in the right direction, or confirm i'm not crazy that would be excellent. Thanks!

davemckain commented 9 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.)

ccreel commented 9 years ago

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?

ghost commented 9 years ago

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!!

screen shot 2014-11-10 at 9 22 05 pm

ghost commented 9 years ago

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 :)

ccreel commented 9 years ago

@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.

davemckain commented 9 years ago

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.

ghost commented 9 years ago

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?

davemckain commented 9 years ago

@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!

davemckain commented 9 years ago

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!

davemckain commented 9 years ago

@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?

ghost commented 9 years ago

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.

ghost commented 9 years ago

Please have her contact Kevin Campbell (kcampbell [at] kobellsystems.com).