Comment regarding constraint on extensions in xAPI Profiles.

[rramire...@soartech.com]

Hello! 

This is just a comment related to the following constraint, as it appears in xAPI Profiles specs: 

"Statements including extensions defined in a Profile MUST:

• only use a ContextExtension in context
• only use a ResultExtension in result
• only use an ActivityExtension in an Activity Definition"

It seems to me that the only reason for having this constraint is that xAPI specs define each extension point as a dictionary. In other words, if xAPI would had defined each extension as an array of dictionaries I think this limitation could be removed. Is my understanding correct? Also, would it be valuable to have extensions defined as an array of dictionaries in a future version of xAPI, so that multiple extensions can be easily combined in xAPI Profiles, or would that change complicate xAPI specs unnecessarily? 

Thanks,

Ruben.

[andrew...@watershedlrs.com]

That's not the only reason. The Activity Definition has some special behavior that makes it different from context and result extensions, and it's important for extensions to be used in the place that a Learning Record Consumer expects them to be found. 

Why would you want to use an extension in a different place?

[rramire...@soartech.com]

Thanks Andrew. I just realized that the way I wrote my prior message is confusing. What I see as a constraint is not that a ContextExtension object can only be in context, and an ActivityExtension in Activity Definition, etc. What triggered my curiosity was the limit of only one data model of the corresponding type for each extension point. 

Let's assume that a hypothetical xAPI profile defines multiple data models of type, let's say, ContextExtension. My question then is: Are there practical situations in which we can benefit from defining a type of statement so that, for instance, its context extension point could contain a collection of data models that are all of type ContextExtension? I think that could be the case if the exact combination of those ContextExtension data models to be used can only be determined at the moment that the activity is generating statements (dynamic, multi-contextual environments?).

Any thoughts about this?

Thanks!

Ruben.

[andrew...@watershedlrs.com]

I not think the profile spec restricts you to a single extension of each type (xAPI certainly doesn't). 

The requirement "only use a ContextExtension in context" has the same meaning as "only use any ContextExtensions in context", not  "only use one ContextExtension in context". 

[Russell Duhon]

Hi Ruben,

The reason for this is just to simplify reasoning about extensions, so a particular extension (defined in xAPI Profiles), with a particular ID (the URI key for the extension), can only be used in one of context, result, or activity definitions. So, for example, an extension with ID http://example.org/extensions/omega in xAPI, generally, could be used in a few places:

{

  "context": { "extensions": { "http://example.org/extensions/omega": _value of extension_ }},

  "result": { "extensions": { "http://example.org/extensions/omega": _value of extension_ }},

  "object": {"definition": { "extensions": { "http://example.org/extensions/omega": _value of extension_ }}}

  ...

}

(and, in addition to object, in all of the Activities in context activities). But if that extension is defined in xAPI Profiles, it can be used in context OR result OR any activity definition, and a similar extension in another location would need a new identifier.

You can still have as many extensions as you want in each of those. You can only have one instance of each extension in each extensions object, as an extension is defined by a unique key, but extensions are free to define themselves as, for example, arrays of multiple values. For example, this is a perfectly fine looking extensions object:

{

  "http://example.org/extensions/omega": { "alpha": 7 },

  "http://example.org/extensions/cromulence_levels": [3, 8, 4, 29],

  "http://example.org/extensions/defenestrations": 191

}

Let me know if I can elaborate more on any of the above.

Sincerely,

Russell

--
You received this message because you are subscribed to the Google Groups "xAPI-Specification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xapi-spec+unsubscribe@adlnet.gov.