Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Talk:COSMOS Design 204959"

Line 16: Line 16:
 
<font color="#336633">
 
<font color="#336633">
 
The APIs defined for the SML repository are very generic.  The interfaces will allow any generic SML document to be processed.  It's only our implementation that extends the set of APIs to include convenience classes for processing facet-based models.  I will update the terminologies section of the document but I don't agree with introducing a new term.
 
The APIs defined for the SML repository are very generic.  The interfaces will allow any generic SML document to be processed.  It's only our implementation that extends the set of APIs to include convenience classes for processing facet-based models.  I will update the terminologies section of the document but I don't agree with introducing a new term.
 +
</font>
 +
 +
<font color="#336699">
 +
Ali, if you introduce or not new terms is irrelevant and less important, my point here is that I don't understand your current SML repository definition and I want you to clarify this.
 
</font>
 
</font>

Revision as of 11:49, 15 October 2007

This page includes all the discussion for COSMOS Design 204959.

[Sheldon's comment] I assume the apis will throw some sort of exception. For example if a user specifies a data provider that is not supported by the handler it should throw some sort of unsupported exception.

Yes, there are a few exceptions that are included:

  • SelectorHandleException
  • UnsupportedDataProvider
  • UnsupportedSelectorHandler


[Valentina's comment] I still have a hard time mapping the SML repository notion used here to its real meaning. Reading the document content it seems that SML repository in this context is the set of java API’s implemented in COSMOS which allows generic interaction with any repository containing SML compliant data ( or generic SML model ). In this context, SML repository is NOT the COSMOS SML repository we also call Data Center repository. If I got it right I suggest changing the name to 'API for generic SML models' or something similar.

The APIs defined for the SML repository are very generic. The interfaces will allow any generic SML document to be processed. It's only our implementation that extends the set of APIs to include convenience classes for processing facet-based models. I will update the terminologies section of the document but I don't agree with introducing a new term.

Ali, if you introduce or not new terms is irrelevant and less important, my point here is that I don't understand your current SML repository definition and I want you to clarify this.

Back to the top