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] Updated: (ODATA-537) Ordering of navigationLink and associationLink annotations in JSON


     [ http://tools.oasis-open.org/issues/browse/ODATA-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hubert Heijkers updated ODATA-537:
----------------------------------

    Proposal: 
Keep the ordering of associationLink and navigationLink as described in 8.2 of the JSON format.

In 8.2 change the following sentence:

"The association link for a navigation property is only represented if the client requests odata.metadata=full or the association link cannot be computed by appending /$ref to the navigation link."

into:

"The association link for a navigation property is only represented if the association link cannot be computed by appending /$ref to the navigation link."

Update example 10 by removing the associationLink annotations.


  was:See description.


@Mike: Wouldn't they always come 'together' anyway because they are both annotations on the navigation property and by definition annotations on a property have to precede the property they annotate?

Either way the order is fine. However your comment lead me to conclude that in odata.metadata=full we always include these irrespective of the fact if the property is expanded or not correct?

Suggestion/proposal, could we change the requirement for the associationLink to be included to only when it can't be computed by appending /$ref to the navigationLink? As of v4 we have neatly cleaned things up and standardized around $ref for references. Typically, for services following convention everywhere, you'd always be able to add /$ref to links that refer to entities or collections thereof. It appears as if associationLink is th only exception were we return the URL to the reference.

Adjusted my proposal accordingly.

> Ordering of navigationLink and associationLink annotations in JSON
> ------------------------------------------------------------------
>
>                 Key: ODATA-537
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-537
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData JSON Format
>    Affects Versions: V4.0_CS01
>         Environment: [Applied]
>            Reporter: Hubert Heijkers
>            Assignee: Ralf Handl
>            Priority: Minor
>             Fix For: V4.0_CSD03
>
>
> 8.2 - Association Link specifies that if both navigationLink and associationLink are represented, for example in the odata.metadata=full case, that the associationLink MUST immediately precede the navigationLink.
> Example 10 however shows two cases were both links are represented however they are in the opposite order of what is specified in 8.2.
> Unless there is a specific reason why associationLink MUST precede the navigationLink, presuming an order needs to be enforced in the first place, I'd propose to have navigationLink precede the associationLink, as associationLink builds on, if following convention, the navigationLink.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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