There seem to be 3 core issues people are struggling with:
(1) What is the best Name for 'Bags'
This we thought long and hard about.
Given that they are Unordered and that AtomPub already uses Collection, we think Bag while not ideal is the best we've got.
However we are all ears if anyone has a compelling alternative.
(2) Everyone wants to be able to use query options with Bags.
$expand, $top, $skip, $select: Because Bags are structurally part of the entity they are designed for scenarios where there are multiple but not a great number of members.
So when the Bag are included in the results either implicitly or explicitly (using $select) they are always $expand(ed) and because there is not supposed to be a great number of members it is all or nothing so $skip and $top makes no sense.
$filter: Items in a Bag can't be accessed by index (it is unordered) or by identity (they only contain ComplexTypes or Primitives which have no identity) so that really just leaves Any/All type queries
i.e something like this:
~/People/?$filter=any(Addresses/City) eq 'Redmond'
Unfortunately, despite my made up URI, Any/All isn't supported in OData yet.
So - for now - that leaves no query support.
(3) Given the - current - lack of query option support are Bags still useful?
Yes. We think Bags are still useful.
Bags are designed for situations where an Entity has more than one 'something' and those something's should always be passed with the entity (unless explicitly excluded using $select).
Good examples include:
* Addresses
* EmailAddresses
* Aliases
* Identities
* Tags
* etc
We think being able to retrieve a Person and all their email addresses, without the bloat associated with a full EmailAddress entity, and the semantics implied by entities (EmailAddresses is not a feed, and EmailAddresses have identities, etc) is still useful.
Any other concerns? Or suggestions?
Other than of course your xsd/edm one Erik ? :)
Alex
-----Original Message-----
From: OData Mailing List [mailto:[log in to unmask]] On Behalf Of Nuno Filipe Godinho
Sent: Tuesday, September 28, 2010 5:21 AM
To: [log in to unmask]
Subject: Re: [New Proposal] - Support for Bags
Hi Agree with Erik. This is one very interesting idea and I see the need and how to apply this, but having support only for the '$format' option turns this to something without real applicability, since all the scenarios I was thinking about would benefit from the options supported by odata, and without them I won't even consider it.
About calling it Bag, I don't really know if this is the right naming for this, I would like to see it name something like list, or collection, because this is really what we want here. But I understand why it's called 'Bag' in the proposal, because if you don't have any support for Odata options in it, it will work really like an opaque element. Don't you agree?
Nuno Filipe Godinho
Independent Consultant
DISCLAIMER: This message is confidential and intended exclusively for the addressee. If you received this message by mistake please inform the sender and delete the message and attachments. No confidentiality nor any privilege regarding the information is waived or lost by any mistransmission.
-----Original Message-----
From: OData Mailing List [mailto:[log in to unmask]] On Behalf Of Erik Johnson
Sent: terça-feira, 28 de Setembro de 2010 08:50
To: [log in to unmask]
Subject: Re: [New Proposal] - Support for Bags
I totally get the need to do this, but hate the idea of what's effectively an opaque and dead-end value. You can't compose the query beyond the "bag", the only query string option is "$format", and bag elements cannot be individually addressed - what good is that? If my data format must be preconceived on both ends, why wouldn't I use a strongly-typed service to do it? I (sort of) understand wanting to avoid implying ordered or index-based access for, um, bag data, but what about key-based access?
On one hand, a "bag" is a weak means to compensate for the lack of data trees in OData (actually by EDM), which is ironic given that Xml and Sql both support them. I REALLY wish this could be thought through more holistically, because that's an acute OData pain point. How about expanding EDM to support nested complex types - implemented as subordinate tables in SQL? I know I sound like a broken record, but XSD has all these constructs and using them for data binding has been thought through at the W3C (http://www.w3.org/TR/2007/WD-xmlschema-patterns-20071031/).
On the other hand, a "bag" is a catch-all container for non-text data.
Why not tag the EDM to associate values to standard MIME types (or even Microformats). You could then identify a value concretely as an image (say, for Pivot). Also, providers should be able to put non-text values on the wire, as attachments, using the multi-part message standard.
That way, large (or even streaming) types could be transmitted without having to be encoded within the AtomPub payload.
-----Original Message-----
From: OData Mailing List [mailto:[log in to unmask]] On Behalf Of Andy Conrad
Sent: Monday, September 27, 2010 8:35 PM
To: [log in to unmask]
Subject: Re: [New Proposal] - Support for Bags
We actually had originally called the type collection - but because of the fact that collections were already a first class concept in AtomPub, we wanted to avoid concept confusion.
We also considered list & array- but turned those down since as you say below, those names imply ordering and index based access.
multiset was the other option - but we decided bag was a better name and less stuffy.
We may also eventually add query support if we add support for ANY / ALL
/ Aggregates to the query language. In other words, the lack of query
support for bags is currently a result of the lack of appropriate operators and not a limitation specific to bags.
Andy
-----Original Message-----
From: OData Mailing List [mailto:[log in to unmask]] On Behalf Of John Spurlock
Sent: Monday, September 27, 2010 4:46 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [New Proposal] - Support for Bags
to make sure i understand the proposal:
- bag properties allow duplicate values
- bag properties are not queryable in any way e.g.
$filter=emailAddresses contains [log in to unmask] is not possible (seems to limit their usefulness...)
- no literal form necessary (since they are not valid in uri query params that would require it)
- bags of bags allowed
- all values transferred back and forth in get/modify scenarios (i.e. no appending to bags)
i'm with scott seely re: the name 'bag', but array/list are not accurate either (no implied ordering), i'd vote for 'collection'
On Mon, Sep 27, 2010 at 5:25 PM, Alex James <[log in to unmask] <mailto:[log in to unmask]<mailto:[log in to unmask]<mailto:[log in to unmask]>> >wrote:
> Everyone,
>
> Ahmed Moustafa just posted a new proposal (
> http://www.odata.org/blog/2010/9/27/adding-support-for-bags
<http://www.odata.org/blog/2010/9/27/adding-support-for-bags> ) to the
> OData blog.
>
> The proposal adds the ability to add a bag or collection of primitives
> or complex types to an entity like this:
>
> <Property Name="EmailAddresses" Type="Bag" Nullable= "False">
> <TypeRef Type= "Edm.String" Nullable= "False"/> <!-- Primitive
> Bag
> -->
> </Property>
>
> or this:
>
> <Property Name="Addresses" Type="Bag" Nullable= "False">
> <TypeRef Type= "Model.Address" Nullable= "False"/> <!--
> ComplexType Bag -->
> </Property>
>
> Bags differ from relationships/navigation properties, because they are
> *structurally* part of the entity.
> As always we are keen to hear what you think.
>
> Thanks
> Alex
>
> ######################################################################
> ##
>
> To unsubscribe from the ODATA list, click the following link:
> http://mailinglist.odata.org/SCRIPTS/WA-ODATA.EXE?SUBED1=ODATA&A=1
<http://mailinglist.odata.org/SCRIPTS/WA-ODATA.EXE?SUBED1=ODATA&A=1>
>
########################################################################
To unsubscribe from the ODATA list, click the following link:
http://mailinglist.odata.org/SCRIPTS/WA-ODATA.EXE?SUBED1=ODATA&A=1
<http://mailinglist.odata.org/SCRIPTS/WA-ODATA.EXE?SUBED1=ODATA&A=1>
########################################################################
To unsubscribe from the ODATA list, click the following link:
http://mailinglist.odata.org/SCRIPTS/WA-ODATA.EXE?SUBED1=ODATA&A=1
<http://mailinglist.odata.org/SCRIPTS/WA-ODATA.EXE?SUBED1=ODATA&A=1>
Click
https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==
ZNck7g6yVr0kgeXJoueGUxyGLELryxzq6kakVWf!6zCig
<https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==
JZNck7g6yVr0kgeXJoueGUxyGLELryxzq6kakVWf!6zCig> == to report this email as spam.
--------------------------------------------------------
This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. Any views and/or opinions expressed in this e-mail are of the author only and do not represent the views of Epicor Software Corporation or any other company within its group.
This message has been scanned for malware by Websense. www.websense.com<http://www.websense.com>
########################################################################
To unsubscribe from the ODATA list, click the following link:
http://mailinglist.odata.org/SCRIPTS/WA-ODATA.EXE?SUBED1=ODATA&A=1
########################################################################
To unsubscribe from the ODATA list, click the following link:
http://mailinglist.odata.org/SCRIPTS/WA-ODATA.EXE?SUBED1=ODATA&A=1
########################################################################
To unsubscribe from the ODATA list, click the following link:
http://mailinglist.odata.org/SCRIPTS/WA-ODATA.EXE?SUBED1=ODATA&A=1
|
