adlnet / xapi-profiles

A set of documents addressing the structure of and supporting services for xAPI Profiles.

Home Page:https://adlnet.gov/projects/xapi/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

allowedSolo and statement template re-use

garemoko opened this issue · comments

Is it allowed to re-use a statement template from one profile as part of a pattern in another?

If yes, this could make use of allowedSolo complex and a single template pattern is more appealing.

Looking through the spec briefly I can't see anywhere that says a pattern can't use templates from other profiles.

Getting rid of allowedSolo and instead allowing single statement patterns would also get rid of the need for the implied pattern concept which is an added complexity.

Re-using statement templates is not intended currently and might end up forbidden; there's a lot of complexity around the versioning issue

there's a lot of complexity around the versioning issue

Please elaborate :-)

I can imagine a scenario where an interactive video profile wants to re-use a question statement template from a quiz profile.

The versioning complexity is, if you identify a statement template by URI, which version of it applies if that URI is used in multiple profile versions?

One way around this would be to require that, if a statement template changes (in the behavior-changing attributes), it is given a new URI. Of course, then the referencing profile would want to monitor for updated statement templates, and there are some interesting questions about the exact retrieval rules, but nothing insurmountable.

I do see the outline of the use case, though my guess is in many cases it'll turn out another approach is better.

But there's some definitely interesting possibilities with allowing it, too. I think the URI-changing requirement would overcome most of my objections, if people are okay adding that as well.

Re: broader allowedSolo use, I'm open to the possibility of removing it (and allowing single-statement sequences only in primary patterns and of a template). The main burden it removed on LRPs was having to generate a registration just for one statement (since allowedSolo allowed non-registration statements in that one case).

Will be removed and normalized with the rest of the spec

Looks like yes, we include statement template reuse and the concomitant requirement

Alternative way would be to use reification:

_:other a TemplateReference
    _:profileversion http://version/of/that/profile/1.8
    _:template http://template/from/that/profile


sequence: [_:other, ...]