Thanks Nikola - I like your term "CCTS instantiation model" - that is
what the UN/CEFACT ATG group is working on.
For [1], you wrote:
<Quote1>
[1] CCTS abstract model -> RIM
This is what I think Joe is referring to as "RIM binding". I'd say this
could be sufficient. Subteam certainly shouldn't attempt this:
</Quote1>
Did you mean to say "Subteam certainly SHOULD attempt this"? You also
wrote "shouldn't" for [2], so I thought that at least one of the these
should be "should" (pardon the tricky English!)
For [3], you wrote:
[3] CCTS instantiation models -> RIM
<Quote2>
I thought that subteam might need to address [3], but I see that this is
not necessary, because implementations of [3] would (should) be
constrained by [1].
</Quote2>
I agree - in terms of a schema and XML instance document (unrelated to
this, but just for example purposes), we can think of [1] as the schema
and [2] as the XML instance document that must conform to [1].
Thanks,
Joe
Nikola wrote:
>
> <Joe>
> Thanks Farrukh. Would you be willing to elaborate on one point:
>
> <Quote>
> Experience with many pilots suggests that the best approach is to have
> an XML format for CCTS content with ebRIM format for CCTS metdata. So I
> would reccomend both XML serialization format (outside of binding) and
> binding to ebRIM metadata.
> </Quote>
>
> It would be very helpful.
> </Joe>
>
> (NB: I might misinterpret some CC related facts):
>
> I'd like to enumerate some steps that might help with defining the scope.
> One can assume that this is possible:
>
> [1] CCTS abstract model -> RIM
>
> This is what I think Joe is referring to as "RIM binding". I'd say this
> could be sufficient. Subteam certainly shouldn't attempt this:
>
> [2] CCTS abstract model -> CCTS instantiation models
>
> Here I assume that something like UBL would be a member of "CCTS
> instantiation models".
>
> And, subteam doesn't need to address this:
>
> [3] CCTS instantiation models -> RIM
>
> I thought that subteam might need to address [3], but I see that this is not
> necessary, because implementations of [3] would (should) be constrained by
> [1].
>
> Regards,
> Nikola
