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

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

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


Subject: [OASIS Issue Tracker] (ODATA-696) Support "interfaces" for casting entities to multiple different types


    [ https://issues.oasis-open.org/browse/ODATA-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62749#comment-62749 ] 

Mark Biamonte commented on ODATA-696:
-------------------------------------

I am trying to visualize how an implementation of this may work.  This is what I am coming up with.

<ComplexType Name="SmartDevice">
	<Property Name="Manufacturer" Type="Edm.String" Nullable="false"/> 
	<Property Name="Model" Type="Edm.String" Nullable="false"/> 
	<Property Name="Version" Type="Edm.String" Nullable="false"/> 
	<Property Name="IpAddress" Type="Edm.String" Nullable="false"/> 
</ComplexType>

<EntityType Name"Vehicle">
    <Key>
		<PropertyRef Name="Id" />
    </Key>
    <Property Name="Id" Type="Edm.Int64" Nullable="false">
	<Property Name="Manufacturer" Type="Edm.String" Nullable="false"/> 
	<Property Name="Model" Type="Edm.String" Nullable="false"/> 
	<Property Name="Year" Type="Edm.String" Nullable="false"/>
	<Property Name="Color" Type="Edm.String" Nullable="false"/>
	<NavigationProperty Name="Options" Type="Collection(OptionItem)"
</EntityType>

<EntityType Name="SmartVehicle" BaseType="Vehicle" Implements="SmartDevice">
	<Property Name="Version" Type="Edm.String" Nullable="false"/> 
	<Property Name="IpAddress" Type="Edm.String" Nullable="false"/> 
</EntityType>

Does this look right?

> Support "interfaces" for casting entities to multiple different types
> ---------------------------------------------------------------------
>
>                 Key: ODATA-696
>                 URL: https://issues.oasis-open.org/browse/ODATA-696
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData CSDL, OData URL Conventions, Vocabularies
>    Affects Versions: V4.0_OS
>         Environment: Interfaces
>            Reporter: Michael Pizzo
>            Assignee: Michael Pizzo
>            Priority: Minor
>              Labels: Extension, GoodIdea
>             Fix For: V4.01_WD01
>
>
> OData's single-inheritance type model works well for many types of ontologies where new types are specializations of existing types, and maps well to class definitions in popular programming languages. However, single inheritance does not describe the fact that an instance of a type can play multiple different roles.
> Vocabularies were introduced to OData in order to enable the definition of common schemas that could be shared across a particular industry or enterprise. Vocabularies allow the ability to share semantic information, such as the fact that a particular instance represents some generic concept.
> Entity models can use these shared schema in defining a data model, for example through derivation, or can map properties of a defined entity to properties of an entity from a shared model. However, we don't have a common way for a service to specify that an entity can be treated (i.e., cast) to another entity outside of the single-inheritance hierarchy, and requiring inheritance to model ontologies is overly restrictive in many cases. Also, some ontologies (like schema.org) make use of multiple inheritance, making it difficult for an entity to derive, for example, from both an individual and an organization.
> Odata defines clear semantics for casting entities of one type to a different type in requests urls, filters, etc. Services can support casting instances to any type, but can currently only advertise the ability to cast to a single (derived) type.
> Adding a new "implements" annotation term to the Core vocabulary allows a service to advertise the fact that one type can be cast to one or more other types using existing cast rules. This rule is entirely backward compatible; it doesn't introduce any incompatible behavior and is entirely safe for a client to ignore.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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