[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] Re: Republica Case Study (Was: Re: [regrep] Web Site update request)
Joe, For the record - W3C do not check implementations. If a vendor reports an implementation - they post it to their /implementations# link. I guess they let the marketplace decide how much or little of the spec' the implementation is actually using. HINT: unless you have formal compliance test suites - its a little hard to throw rocks in the glasshouse ; -) Especially as the only way you discover spec' issues and improvements is to implement... Cheers, DW. ----- Original Message ----- From: "Chiusano Joseph" <email@example.com> To: "Diego Ballvé" <firstname.lastname@example.org> Cc: <email@example.com> Sent: Friday, September 26, 2003 9:13 AM Subject: Re: [regrep] Re: Republica Case Study (Was: Re: [regrep] Web Site update request) > <Quote1> > "The project was not fully aligned with OASIS ebXML Standards > </Quote1> > > With all due respect to the hard work that I'm sure went into this, it > still puzzles me as to why OASIS would post something that is not in > line with the standards that have been created by an OASIS TC. I don't > believe that W3C posts products implementations that do not conform to > their Recommendations. > > <Quote2> > Now for CCRIM disclaimer specifically, can you give me the > correct long form of CCRIM?? > </Quote2> > > At this point I would recommend referring to this as "the work of the > Core Components Review Subcommittee of OASIS/ebXML Registry TC". > > Thanks Diego! > Joe > > Diego Ballvé wrote: > > > > Chiusano Joseph wrote: > > > > > > <Quote> > > > Maybe all that is needed is a statement in the paper that states that > > > this work pre-dates CCRIM and will be suprceded by it. > > > </Quote> > > > > > > I think that would be great - thanks Farrukh. I would be fine if it > > > simply states that: > > > > > > (a) It pre-dates CCRIM, and > > > > > > (b) The approaches defined in the paper are not necessarily > > > in line with > > > those to be specified in the forthcoming OASIS/Registry TC Core > > > Components Technical Note > > > > Wow, I didn't expect our case-study to create such polemic. But > > suggestion accepted: I think you're absolutelly right on making > > clear that it is not necessarily aligned with ebXML work. I'm > > working on the changes and I've added the following disclaimer: > > > > "The project was not fully aligned with OASIS ebXML Standards and > > should not be used as a reference implementation. Rather, this > > case study should be read as a report of a successful experience > > based on ebXML Standards. Furthermore, this case study should > > inspire similar experiences to take place and to be shared > > throughout the ebXML community. See section 3 for used > > specifications and degrees of adoption." > > > > Now for CCRIM disclaimer specifically, can you give me the > > correct long form of CCRIM?? > > > > > I don't think it's necessary to say that it will be > > > superceded by it. I > > > agree that we need to recognize Diego's work, but we also need to > > > recognize the work of the other members of the CC Review team > > > as well by > > > ensuring that there is no confusion as to the recommendations > > > coming fom > > > the team. > > > > I reckon. I'll make sure I that is clear in the paper. I'll > > also add Acknowledgments to cc-review since ideas from there were/ > > will be taken into consideration for any future move concerning > > CCs in the Registry and Republica's LomakeFi Form Assembler tool. > > > > Diego ---------------------------------------------------------------------------- ---- > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.