Re: [regrep] question about relationship between JSR 170 and ebXMLRegistry

[Duane Nickull <dnickull@adobe.com>]

Peter:

To add to Farrukh's commentary, I firmly believe that the approach of 
abstracting the Registry API from the JAVA language is better in the 
long run (XML encoded as UTF-8 & 16).  This does not prevent someone 
from adding an additional Java APi (RMI registry client?).  I love java 
but the current approach allows clean separation and no dependencies 
other than XML parsing.

Duane

Farrukh Najmi wrote:

> Peter Kacandes wrote:
>
>> Hi,
>>  
>> Some time ago there was some discussion on the alias about the 
>> relationship between the reg/rep and content mgmt. systems.
>>  
>> Among other things, I seem to recall there were general conclusions 
>> (roughly implying) that the reg/rep could provide interoperability 
>> among various cm systems.
>>  
>> So, I'm wondering how people see the relationship between JSR 170 and 
>> reg/rep.
>>  
>> Here's the description of the JSR:
>>
>> The API should be a standard, implementation independent, way to 
>> access content bi-directionally on a granular level within a content 
>> repository. A Content Repository is a high-level information 
>> management system that is a superset of traditional data 
>> repositories. A content repository implements "content services" such 
>> as: author based versioning, full textual searching, fine grained 
>> access control, content categorization and content event monitoring. 
>> It is these "content services" that differentiate a Content 
>> Repository from a Data Repository.
>>
>> Many of today's (web)applications are interacting with a content 
>> repository in various ways.
>>
>> This API proposes that content repositories have a dedicated, 
>> standard way of interaction with applications that deal with content. 
>> This API will focus on transactional read/write access, binary 
>> content (stream operations), textual content, full-text searching, 
>> filtering, observation, versioning, handling of hard and soft 
>> structured content.
>>
>>     It seems like this would address some of the things that were
>>     being discussed on the thread without needing to have a reg/rep
>>     involved.
>>      
>>     I realize I'm probably missing some big distinctions, but I know
>>     I can count on you bright people to wise up the marketing guy.
>>      
>>     tia
>>      
>>     pk
>>      
>>
> I am Sun's rep to JSR 170.
>
> <disclaimer>
> In the last few months I have been relatively disengaged.
> My information below may be somewhat dated.
> It may also be negatively pre-disposed.
> </disclaimer>
>
> JSR 170 is a Java API being developed within the JCP and will 
> eventually be a standard Java API for content repositories.
>
> ebXML Registry is an XML Standard that may have implementations in 
> Java and other platforms.
>
> JAXR is a JCP approved and fairly established Java API for XML 
> Registries and Repositories. It is also a required part of the J2EE 
> 1.4 platform.
>
> Very early in the JSR 170 life cycle I expressed the concern that it 
> was duplicating work done in JAXR API and ebXML Registry without 
> having any relationship to those  pre-existing standards. I suggested 
> that JSR 170 align with JAXR API and ebXML Registry to address that 
> concern.
>
> The JSR 170 expert group decided not to alter course in light of that 
> suggestion and is continuing to chart their own course.
>
> JSR 170 EG has several content management vendors as participants 
> (more so than ebXML Registry TC).
>
> JSR 170 lacks most of the features of ebXML Registry.
>
> JSR 170 is a Java API while ebXML Registry is an XML Standard and a 
> web service.
>
> Looking at my crystal ball, I personally do not quite see the long 
> term viability for JSR 170 because it is not based on existing XML 
> standards for Registry/Repository (ebXML Registry, ISO 11179 etc).
>
>-- 
>Regards,
>Farrukh
>  
>
> 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. 



-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com