RE: [corona-dev] ProjectContainer Definition

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

RE: [corona-dev] ProjectContainer Definition

From: "Kalka, Edyta" <Edyta.Kalka@xxxxxxxxxxxxxxxx>
Date: Wed, 12 Jul 2006 15:41:21 +0200
Delivered-to: corona-dev@xxxxxxxxxxx
List-archive: <http://eclipse.org/pipermail/corona-dev>
List-help: <mailto:corona-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/corona-dev>, <mailto:corona-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/listinfo/corona-dev>, <mailto:corona-dev-request@eclipse.org?subject=unsubscribe>
Thread-index: AcalKXG195S1ahUdQGqtvu5eCTeZswAZMTdQAAk07iAAAPHoYA==
Thread-topic: [corona-dev] ProjectContainer Definition

The repository definition from Dennis’s answer comes from generic repository schema.

In generic container schema repositories references looks as follows:

<xs:element name="repositories" type="con:repositories" minOccurs="0" maxOccurs="1"/>

<xs:complexType name="repository">

<xs:attribute name="uri" type="xs:anyURI" use="required"/>

<xs:attribute name="type" type="xs:anyURI" use="required"/>

</xs:complexType>

From this answer I understood that repository type attribute in generic container model is unnecessary and should be only needed in project container model – is that right ?

Edyta

From: corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of O'Flynn, Dennis
Sent: 12 lipca 2006 15:11
To: Corona development
Subject: RE: [corona-dev] ProjectContainer Definition

Edyta – Thanks for the details re: generic container. This will be helpful.

I would like to emphasis a key point – “repositories”.

The generic container allows for the definition of repositories. Each repository has is defined as:

<xs:complexType name="repository">

<xs:sequence>

<xs:element name="repository-uri" type="rep:repository-uri"/>

<xs:element name="repository-type" type="xs:anyURI"/>

<xs:element name="repository-description" type="xs:string"/>

<xs:element name="repository-configurations" type="rep:repository-configuration" maxOccurs="unbounded"/>

<xs:element name="relationship-resource-set" type="rep:relationship-file" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="name" type="xs:string" use="required"/>

<xs:attribute name="repository-configuration" type="xs:string" use="required"/>

</xs:complexType>

The ProjectContainer defines the context for the generic container. This also includes the definition of each repository “type”. The “type” of repository will have meaning for the ProjectContainer context. However, it may have no meaning for other implementations of a generic container.

From: corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Kalka, Edyta
Sent: Wednesday, July 12, 2006 7:12 AM
To: Corona development
Subject: RE: [corona-dev] ProjectContainer Definition

I will describe how looks generic and project context container definition now:

Schema describing generic container is as follows:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:con="http://www.eclipse.org/corona/server/container" targetNamespace="http://www.eclipse.org/corona/server/container">

<xs:complexType name="context-container">

<xs:sequence>

<xs:element name="container-uri" type="xs:anyURI" minOccurs="0"/>

<xs:element name="container-path" type="con:container-path-element" maxOccurs="1" minOccurs="0"/>

<xs:element name="container-type" type="xs:anyURI" minOccurs="0"/>

<xs:element name="container-description" type="xs:string" minOccurs="0"/>

<xs:element name="repositories" type="con:repositories" minOccurs="0" maxOccurs="1"/>

<xs:element name="subcontainers" type="con:subcontainers" minOccurs="0" maxOccurs="1"/>

<xs:element name="container-properties" type="con:container-properties" minOccurs="0" maxOccurs="1"/>

<xs:element name="relationship-resource-set" type="con:relationship-resource-set" minOccurs="0" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="relationship-resource-set">

<xs:sequence>

<xs:element name="relationship-file" type="con:relationship-file" maxOccurs="unbounded" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="relationship-file">

<xs:attribute name="type" type="xs:string" use="required"/>

<xs:attribute name="version" type="xs:string" use="required"/>

<xs:attribute name="uri" type="xs:anyURI" use="required"/>

</xs:complexType>

<xs:complexType name="repositories">

<xs:sequence>

<xs:element name="repository" type="con:repository" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="repository">

<xs:attribute name="uri" type="xs:anyURI" use="required"/>

<xs:attribute name="type" type="xs:anyURI" use="required"/>

</xs:complexType>

<xs:complexType name="container-properties">

<xs:sequence>

<xs:element name="container-property" type="con:container-property" maxOccurs="unbounded" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="container-property">

<xs:attribute name="name" type="xs:string" use="required"/>

<xs:attribute name="value" type="xs:string" use="required"/>

</xs:complexType>

<xs:complexType name="container-path-element">

<xs:sequence>

<xs:element name="container-path-element" type="xs:anyURI" maxOccurs="unbounded" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="subcontainers">

<xs:sequence>

<xs:element name="context-container" type="con:context-container" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

Thus, for now generic container context includes:

- its identifier

- type

- path – which is location in the containers’ tree starting from the root

- description

- list of repositories’ references

- list of subcontainers

- list of container properties

- list of RDF files containing resource relationships – this is feature provided by Glenn and I would ask him for an example of its usage – I don’t have enough information on this subject.

Such container properties like id, type, path is presented in form of URI. If at any point we want to use RDF such URI approach would be useful.

Form of URI is open issue. For now I used the following:

- sample container uri: http://www.eclipse.org/corona/server/container/sampleEclipseProject

- sample container type: http://www.eclipse.org/corona/server/containerTypes/eclipseProject

etc.

- We can extend this with version information like http://www.eclipse.org/corona/server/container/sampleEclipseProject#00.00.01

Should we stay with such URI form or not?

Any other comments?

SDO model code generated on the basis of such schema includes ContextContainer interface (representing data graph root object) in a form:

public interface ContextContainer {

String getContainerUri();

void setContainerUri(String value);

ContainerPathElement getContainerPath();

void setContainerPath(ContainerPathElement value);

String getContainerType();

void setContainerType(String value);

String getContainerDescription();

void setContainerDescription(String value);

Repositories getRepositories();

void setRepositories(Repositories value);

Subcontainers getSubcontainers();

void setSubcontainers(Subcontainers value);

ContainerProperties getContainerProperties();

void setContainerProperties(ContainerProperties value);

RelationshipResourceSet getRelationshipResourceSet();

void setRelationshipResourceSet(RelationshipResourceSet value);

} // ContextContainer

++++++++++++++++++++++++++++++++

Project context container is to extend generic context container. In other words it is our sample specialization of generic container.

However on the server side during new container model registration – container manager will expect implementation of generic ContextContainer interface.

For new container model registration container manager will need information such as id, type, path – this container data has to be set and for this reason it is placed in generic model.

In specialized container model like Project context container we can add any additional information required by modules specific for given system set over corona.

For now project context container schema simply extends generic container:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:con="http://www.eclipse.org/corona/server/container" xmlns:pcon="http://www.eclipse.org/corona/server/container/project" targetNamespace="http://www.eclipse.org/corona/server/container/project">

<xs:import namespace="http://www.eclipse.org/corona/server/container" schemaLocation="./GenericContainer.xsd"/>

<xs:complexType name="project-context-container">

<xs:complexContent>

<xs:extension base="con:context-container">

<xs:sequence>

<!—here can be placed any additional information specific for project container e.g.” icon“ used by client ui à

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:schema>

SDO model code generated on the basis of such schema includes ProjectContextContainer interface (representing data graph root object) in a form:

public interface ProjectContextContainer extends ContextContainer {

} // ProjectContextContainer

Few questions on project context container model definition (once asked but with no feedback):

Do we want to overwrite generic properties like container identifiers inside project container by adding to its schema:

<xs:element name="project-container-uri" type="pcon:project-container-uri"/>

<xs:simpleType name="project-container-uri">

<xs:restriction base="xs:anyURI">

<xs:pattern value="http://www.eclipse.org/corona/server/container/\w*"/>

</xs:restriction>

</xs:simpleType>

From one side: this would give us a method for setting some kind of restrictions over identifier expected form.

But from the other side: notice that corona container manager expects ContextContainer instance and understands its generic properties.

Such container manager has no knowledge on specific container extensions added by any new system build over corona. In this case we would need a mechanism for mapping specific container properties to generic container properties – in our example it would be pointing that project-container-uri represents container-uri from generic container schema.

This could be done: if for instance some extension point would be set for new container registration with a set of arguments allowing for mapping required generic container properties to specific ones.

The question here is if we really need something like this?

Any feedback/comment very welcome!

+++++++++++++++++++++++++++++++++++

So far I described containers models. Now we have repositories models used for defining any needed container repository such as: team member repository (being xml repository for now), cvs repository, bugzilla repository, relational database repository etc. Such repositories’ identifiers are used as references inside container definitions.

Current schema describing generic repository looks as follows:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:rep="http://www.eclipse.org/corona/server/repository" targetNamespace="http://www.eclipse.org/corona/server/repository">

<xs:complexType name="repository">

<xs:sequence>

<xs:element name="repository-uri" type="rep:repository-uri"/>

<xs:element name="repository-type" type="xs:anyURI"/>

<xs:element name="repository-description" type="xs:string"/>

<xs:element name="repository-configurations" type="rep:repository-configuration" maxOccurs="unbounded"/>

<xs:element name="relationship-resource-set" type="rep:relationship-file" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="name" type="xs:string" use="required"/>

<xs:attribute name="repository-configuration" type="xs:string" use="required"/>

</xs:complexType>

<xs:complexType name="repository-uri">

<xs:choice>

<xs:element name="repository-uri-element" type="xs:anyURI"/>

<xs:element name="repository-uri-reference" type="rep:repository-uri-reference"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="repository-uri-reference">

<xs:attribute name="xpath-element-ref" type="xs:string" use="required"/>

</xs:complexType>

<xs:complexType name="relationship-file">

<xs:attribute name="type" type="xs:string" use="required"/>

<xs:attribute name="version" type="xs:string" use="required"/>

<xs:attribute name="uri" type="xs:anyURI" use="required"/>

</xs:complexType>

<xs:complexType name="repository-configuration">

<xs:sequence>

<xs:element name="repository-connection-parameters" type="rep:repository-connection-parameter" maxOccurs="unbounded"/>

<xs:element name="resource-subsets" type="rep:resource-subset" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="name" type="xs:string" use="required"/>

</xs:complexType>

<xs:complexType name="repository-connection-parameter">

<xs:attribute name="name" type="xs:anyURI" use="required"/>

<xs:attribute name="value" type="xs:string" use="required"/>

</xs:complexType>

<xs:complexType name="resource-subset">

<xs:attribute name="type" type="xs:anyURI" use="required"/>

<xs:attribute name="selection-criteria" type="xs:string" use="required"/>

</xs:complexType>

</xs:schema>

Properties like uri, type, description have role similar like in case of containers.

Property repository-configurations contains connection parameters and resource data subsets definition (if we don’t want to retrieve the whole content of given data source e.g. we want to retrieve data only from one table of some database).

Sample definition for team member repository of repository configurations could look like this:

<repository-configuration name="members_1">

<repository-connection-parameters>

<repository-connection-parameter name="fileURI" value="file://c:/org.eclipse.corona/user/coronausers.xml" />

</repository-connection-parameters>

<resource-subsets>

<resource-subset>

</resource-subset>

</resource-subsets>

</repository-configuration>

<repository-configuration name="members_2">

<repository-connection-parameters>

<repository-connection-parameter name="fileURI" value="file://c:/org.eclipse.corona/user/coronausers2.xml" />

</repository-connection-parameters>

<resource-subsets>

<resource-subset>

</resource-subset>

</resource-subsets>

</repository-configuration>

</repository-configurations>

//We can define multiple configurations inside one repository definition and point which one should be currently use by setting its name to repository-configuration attribute of repository root //element.

Our specialized repository model like team member repository etc. extends generic repository.

We can add inside these models anything specific or we could overwrite generic properties like repository-configuration e.g.:

<xs:element name="team-repository-configurations" type="trep:team-repository-configuration" maxOccurs="unbounded"/>

<xs:complexType name="team-repository-configuration">

<xs:sequence>

<xs:element name="team-repository-connection-parameters" type="trep:team-repository-connection-parameter" maxOccurs="unbounded"/>

<xs:element name="team-resource-subsets" type="trep:team-resource-subset" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="name" type="xs:string" use="required"/>

</xs:complexType>

<xs:complexType name="team-repository-connection-parameter">

<xs:attribute name="name" type="trep:connection-parameter-type" use="required"/>

<xs:attribute name="value" type="xs:string" use="required"/>

</xs:complexType>

<xs:simpleType name="connection-parameter-type">

<xs:restriction base="xs:anyURI">

<xs:enumeration value="http://www.eclipse.org/corona/server/connectionParameter/fileURI"/>

<xs:enumeration value="http://www.eclipse.org/corona/server/connectionParameter/fileLocation"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="team-resource-subset">

<xs:attribute name="type" type="trep:resource-subset-type" use="required"/>

<xs:attribute name="selection-criteria" type="xs:string" use="required"/>

</xs:complexType>

<xs:simpleType name="resource-subset-type">

<xs:restriction base="xs:anyURI">

<xs:enumeration value="http://www.eclipse.org/corona/server/resourceSubsetTypes/XPathResultSet"/>

</xs:restriction>

</xs:simpleType>

But in case of overwriting generic properties we would need similar as in case of containers mapping mechanism between generic and specialized properties.

Similarly as in case of containers – sdo repository model code includes GenericRepository interface (in case of generic model) and TeamRepository interface (specialized repository model) (interfaces representing data graph root objects).

++++++++++++++++++++++++++++++++++++++

Regarding the question asked during the conference how to access model data – check some shorten code showing idea how to serialize, deserialize and access to container/repository data:

To load sdo model we need:

// register factory model

protected ExtendedMetaData registerModel() {

ProjectPackageImpl.eINSTANCE.getName();

resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("xml", new ProjectFactoryImpl());

return new BasicExtendedMetaData(resourceSet.getPackageRegistry());

}

//load data graph

protected final void load(HashMap loadOptions) throws Exception {

resourceSet.getResources().clear();

dataGraph = SDOUtil.loadDataGraph(dgByteInputStream, loadOptions);

dgByteInputStream.reset();

}

To access model root object like our ContextContainer instance or ProjectContextContainer instance:

ProjectContextContainer root = (ProjectContextContainer)dataGraph.getRootObject();

To save sdo model:

resource = ((EDataGraph)dataGraph).getDataGraphResource();

resource.save(outputStream, options);

outputStream.close();

++++++++++++++++++++++++++++++++++++++

I concentrated on the static sdo models because:

– for now I don’t see reason for using dynamic ones

- static models looks better in terms of performation (see: http://www-128.ibm.com/developerworks/webservices/library/ws-bestjdbc2/)

+++++++++++++++++++++++++++++++++++++++++++++++++

Open issues:

- is this approach for container/repository modeling ok?

- what about URI form?

- what about overwriting generic properties with properties from specialized models – do we need that? If yes – what mapping mechanism to use etc.?

- what approach should be taken for enabling interface for new container/repository model registration (e.g. extension point usage) ?

- can you see any specific properties for our specialized models not taken into account so far?

- The same for generic properties – what should be added to generic models?

Sorry for long description but I was trying to explain how these issues looks now and on what issues I have no feedback.

Best regards

Edyta

From: corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of O'Flynn, Dennis
Sent: 11 lipca 2006 22:34
To: Corona development
Subject: [corona-dev] ProjectContainer Definition

The following is a draft definition of a ProjectContainer. Please reply to this email thread to update this definition.

What is a ProjectContainer?

A ProjectContainer is an exemplary implementation Corona’s collaboration context framework. It defines the collaboration context for sharing a high lever project definition across multiple Eclipse Workbenches as well as Corona server-side environments.

What is in a ProjectContainer?

Corona’s collaboration context container is a generic container used to manage references to resources. The ProjectContainer provides the context for these resources to be grouped together. The following are the resources referred to by the ProjectContainer:

List of team members who belong to the Project
List of team members who are active (online) within the Project
URL of Project’s home page (optional)

i.e. http://www.eclipse.org/corona

URL of Project’s wiki page (optional)

i.e. http://wiki.eclipse.org/index.php/Corona

URL of Project’s bugzilla page (optional)

i.e. https://bugs.eclipse.org/bugs/

URL of Project’s CVS repository

i.e. cvs:// :pserver:dennis@xxxxxxxxxxxxxxx: /cvsroot/technology (Valid URL ???)

URL of the ECF server used by the Project for collaboration (optional)

i.e. ecftcp://<server>:port/<groupname>

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

Prev by Date: RE: [corona-dev] ProjectContainer Definition
Next by Date: [corona-dev] Eclipse Copyrights and Attribution
Previous by thread: RE: [corona-dev] ProjectContainer Definition
Next by thread: RE: [corona-dev] ProjectContainer Definition
Index(es):
- Date
- Thread

Breadcrumbs