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-712) In chapter 10 we missed to spell out various Context URL templates.


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

Ralf Handl edited comment on ODATA-712 at 6/27/14 3:39 PM:
-----------------------------------------------------------

We could use the {entity}/navprop pattern for "undefined target entity set", because we do this already for the containment case (see 10.1), and we use this pattern in section 10.13 Property Value. 
Section 10.13 is currently implicitly restricted to structural properties, because it refers to section "requesting individual properties", which is (more or less implicitly) restricted to structural properties.

So using the {entity}/navprop pattern would be consistent.

On the other hand I don't like the fact that we put key property values into the context URL, and I cannot recall why we did this. To be consistent we would have to include function parameters in context URLs for function results with undetermined target entity set, which is awkward, and completely impossible for actions.

The new pattern using a qualified type name is sufficient to identify the metadata section that describes the structure of the response. Taking example 24 in 10.13 I would rather see

    http://host/service/$metadata#Collection(Model.Address)
or
    http://host/service/$metadata#Model.Customer/Addresses

instead of 

    http://host/service/$metadata#Customers(1)/Addresses

Using this new pattern also for the containment case and property values would increase consistency and simplify context URL interpretation.


was (Author: ralfhandl):
We could use the {entity}/navprop pattern for "undefined target entity set", because we do this already for the containment case (see 10.1), and we use this pattern in section 10.13 Property Value. 
Section 10.13 is currently implicitly restricted to structural properties, because it refers to section "requesting individual properties", which is (more or less implicitly) restricted to structural properties.

So using the {entity}/navprop pattern would be consistent.

On the other hand I don't like the fact that we put key property values into the context URL, and I cannot recall why we did this. 

The new pattern using a qualified type name is sufficient to identify the metadata section that describes the structure of the response. Taking example 24 in 10.13 I would rather see

    http://host/service/$metadata#Collection(Model.Address)
or
    http://host/service/$metadata#Model.Customer/Addresses

instead of 

    http://host/service/$metadata#Customers(1)/Addresses

> In chapter 10 we missed to spell out various Context URL templates.
> -------------------------------------------------------------------
>
>                 Key: ODATA-712
>                 URL: https://issues.oasis-open.org/browse/ODATA-712
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData ABNF Construction Rules, OData Protocol 
>    Affects Versions: V4.0_OS
>            Reporter: Martin Zurmuehl
>             Fix For: V4.0_ERRATA01
>
>
> For each sub-chapter of chapter 10 the following list contains ALL context URL templates. The new and currently missing ones are marked with "is missing":
> 10.2 Collection of Entities
> Context URL template:
> {context-url}#{entity-set}
> {context-url}#Collection({type-name})                       is missing
> 10.3 Entity
> Context URL template:
> {context-url}#{entity-set}/$entity
> {context-url}#{type-name}                                   is missing
> 10.7 Collection of Projected Entities
> Context URL templates:
> {context-url}#{entity-set}{/type-name}{select-list}
> {context-url}#Collection({type-name}){select-list}           is missing
> 10.8 Projected Entity
> Context URL templates:
> {context-url}#{entity-set}{/type-name}{select-list}/$entity
> {context-url}#{singleton}{select-list}
> {context-url}#{type-name}{select-list}                       is missing
> 10.9 Collection of Projected Expanded Entities
> Context URL template:
> {context-url}#{entity-set}{/type-name}{select-list}
> {context-url}#Collection({type-name}){select-list}           is missing
> 10.10 Projected Expanded Entity
> Context URL template:
> {context-url}#{entity-set}{/type-name}{select-list}/$entity
> {context-url}#{singleton}{select-list}
> {context-url}#{type-name}{select-list}                       is missing
> 10.13 Property Value
> Context URL template:
> {context-url}#{entity}/{property-path}
> {context-url}#{type-name}/{property-path}                    is missing
> 10.16 Operation Result
> Context URL templates:
> {context-url}#{entity-set}{/type-name}{select-list}
> {context-url}#Collection({type-name}){select-list}            is missing
> {context-url}#{entity-set}{/type-name}{select-list}/$entity
> {context-url}#{type-name}{select-list}                        is missing
> {context-url}#{entity}/{property-path}
> {context-url}#{type-name}/{property-path}                     is missing
> {context-url}#Collection({type-name})
> {context-url}#{type-name}



--
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]