OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [regrep-cc-review] Kickoff!


You can't be more right when you say we need to define
we are trying to do here. I took a look at CAM again
and I guess that what I've been proposing and exposing
here relates only to the Conceptual layer while CAM has
gone further and also handled Logical and Phisical layers.
(See Figure 4.1 in [1])

IMO, this is what we should discuss here: How to store CCs
and BIEs in a ebXML Registry. If we decide to do more than
that, ok. Both CAM and Republica have gone further and can
probably contribute if the topic is assembling content or
generating XML Schema based on CCTS stored in a registry.
But, are these in the scope of this review??

Furthermore, I don't see "CC/BIEs in a ebXML Registry" as
a out-of-the-box solution that we can go and show to the
world, but rather a tool used by CAM or Republica's form
assembler, which then can be called out-of-the-box.

Concerning the Contexts discussion, the picture I've
posted shows a (context-free) Person CC and a
in-all-contexts Person BIE for that CC. I'm aware that
you may also have Tax Payer Person BIE, a Worker Person
BIE, etc. but I don't think it compromisses the model.
Assembly doc in the Logical layer takes care of further
details to generate payload (magic?!).


[1] http://cam.swiki.net/.uploads/documents/OASIS-CAM-Specifications-1_0-draft-013-051703.doc

> -----Original Message-----
> From: David RR Webber - XML ebusiness [mailto:Gnosis_@compuserve.com]
> Sent: Thursday, June 05, 2003 4:39 PM
> To: Diego Ballvé
> Cc: regrep-cc-review@lists.oasis-open.org
> Subject: RE: [regrep-cc-review] Kickoff!
> Diego,
> This posting of yours is a gem!  Thanks for your insights.
> The crux of the problem is 
> 'how do the two worlds work together?'
> We have spent a deal of time in the OASIS CAM TC work
> on seeing how to make it so that the model and the
> realization can work in synergy.  When you look at
> real world work - like the OASIS CIQ teams - on name
> and address - you see the challenges and also the
> opportunities. 
> The 'Big Three' that I see we've not yet addressed are:
> Context, Codelists and Construction.
> While your teams approach covers the model - when
> you relate say the notion of 'Person' to the OASIS CIQ
> model - you see that, based on context, there are in
> fact many ways of representing what Person is, in
> both the linguist ways of naming said, and also their
> role and function - and it requires Context to resolve
> the details, and then the construction linkage for the 
> physical payloads must also be addressed.
> So - back to the requirements again - how much
> of this are we looking to do, Phase 1, Phase 2, Phase 3,
> etc.   I'm happy so long as we have a clear set of
> goals (what problem(s) are we addressing?), 
> requirements, and then the roadmap.
> Critically - when we go out to "the world" with this - 
> we need to be able to show them what they
> can do 'out the box' with our deliverables, and
> how it relates to their systems today.
> Thanks, DW.
> ==============================================
> Message text written by Diego Ballvé
> >but I guess we're talking about the same things, just in
> different levels of abstraction. As I've mentioned in a
> previous 'ps', I also have assembly info, but in a
> diferent XML, which I do not store as metadata. Btw, that
> might be the way to handle codelists: adding to metadata
> just a pointer to another registry document. Just crossed
> my mind now..
> Anyway, the most important thing is that one level does not
> invalidate the other.
> <

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]