I assume there would be <link/>'s available inside the <error/> element?
I think it could be handy, altho I'm not sure about the <code/> element, is that intended to be a mirror of the HTTP STATUS CODE returned by a request, or a more higher level, application specific error?
Mark
-- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree
On Mon, Oct 24, 2011 at 10:21 PM, Mike Kelly <mikekelly...@gmail.com> wrote: > What would everyone think about adding some extra bits for error > responses? Something along the lines of:
Yeah, code is intended as an application specific code for the type of error - you're right though this is probably mostly redundant given that http codes should cover the majority of cases.
On Mon, Oct 24, 2011 at 11:14 AM, Mark Derricutt <m...@talios.com> wrote: > I assume there would be <link/>'s available inside the <error/> element?
> I think it could be handy, altho I'm not sure about the <code/> element, is > that intended to be a mirror of the HTTP STATUS CODE returned by a request, > or a more higher level, application specific error?
> Mark
> -- > "Great artists are extremely selfish and arrogant things" — Steven Wilson, > Porcupine Tree
> On Mon, Oct 24, 2011 at 10:21 PM, Mike Kelly <mikekelly...@gmail.com> wrote:
>> What would everyone think about adding some extra bits for error >> responses? Something along the lines of:
I was just thinking whether a rel attribute might somehow make sense, as a way of expressing how the error relates to the target resource, something like <error rel="myapp:expiredrelationship" xmlns:myapp="..."/>.
Something about that feels wrong tho - rel's tend to be outgoing, but is there any reason they can't also be incoming?
-- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree
On Mon, Oct 24, 2011 at 11:24 PM, Mike Kelly <m...@mykanjo.co.uk> wrote: > Yeah, code is intended as an application specific code for the type of > error - you're right though this is probably mostly redundant given > that http codes should cover the majority of cases.
> Links would definitely be allowed
> Cheers, > Mike
> On Mon, Oct 24, 2011 at 11:14 AM, Mark Derricutt <m...@talios.com> wrote: > > I assume there would be <link/>'s available inside the <error/> element?
> > I think it could be handy, altho I'm not sure about the <code/> element, > is > > that intended to be a mirror of the HTTP STATUS CODE returned by a > request, > > or a more higher level, application specific error?
> > Mark
> > -- > > "Great artists are extremely selfish and arrogant things" — Steven > Wilson, > > Porcupine Tree
> > On Mon, Oct 24, 2011 at 10:21 PM, Mike Kelly <mikekelly...@gmail.com> > wrote:
> >> What would everyone think about adding some extra bits for error > >> responses? Something along the lines of:
Error responses relate more to requests than resources which I think implies custom HTTP headers are the way to go in that case.
Thinking about it that's the best approach when a type of error is significant to your application.. maybe we should just drop the <code> element altogether?
On Mon, Oct 24, 2011 at 11:31 AM, Mark Derricutt <m...@talios.com> wrote: > I was just thinking whether a rel attribute might somehow make sense, as a > way of expressing how the error relates to the target resource, something > like <error rel="myapp:expiredrelationship" xmlns:myapp="..."/>.
> Something about that feels wrong tho - rel's tend to be outgoing, but is > there any reason they can't also be incoming?
> -- > "Great artists are extremely selfish and arrogant things" — Steven Wilson, > Porcupine Tree
> On Mon, Oct 24, 2011 at 11:24 PM, Mike Kelly <m...@mykanjo.co.uk> wrote:
>> Yeah, code is intended as an application specific code for the type of >> error - you're right though this is probably mostly redundant given >> that http codes should cover the majority of cases.
>> Links would definitely be allowed
>> Cheers, >> Mike
>> On Mon, Oct 24, 2011 at 11:14 AM, Mark Derricutt <m...@talios.com> wrote: >> > I assume there would be <link/>'s available inside the <error/> element?
>> > I think it could be handy, altho I'm not sure about the <code/> element, >> > is >> > that intended to be a mirror of the HTTP STATUS CODE returned by a >> > request, >> > or a more higher level, application specific error?
>> > Mark
>> > -- >> > "Great artists are extremely selfish and arrogant things" — Steven >> > Wilson, >> > Porcupine Tree
>> > On Mon, Oct 24, 2011 at 10:21 PM, Mike Kelly <mikekelly...@gmail.com> >> > wrote:
>> >> What would everyone think about adding some extra bits for error >> >> responses? Something along the lines of:
On Mon, Oct 24, 2011 at 12:01 PM, Mike Kelly <m...@mykanjo.co.uk> wrote: > Error responses relate more to requests than resources which I think > implies custom HTTP headers are the way to go in that case.
> Thinking about it that's the best approach when a type of error is > significant to your application.. maybe we should just drop the <code> > element altogether?
> Cheers, > Mike
> On Mon, Oct 24, 2011 at 11:31 AM, Mark Derricutt <m...@talios.com> wrote: >> I was just thinking whether a rel attribute might somehow make sense, as a >> way of expressing how the error relates to the target resource, something >> like <error rel="myapp:expiredrelationship" xmlns:myapp="..."/>.
>> Something about that feels wrong tho - rel's tend to be outgoing, but is >> there any reason they can't also be incoming?
>> -- >> "Great artists are extremely selfish and arrogant things" — Steven Wilson, >> Porcupine Tree
>> On Mon, Oct 24, 2011 at 11:24 PM, Mike Kelly <m...@mykanjo.co.uk> wrote:
>>> Yeah, code is intended as an application specific code for the type of >>> error - you're right though this is probably mostly redundant given >>> that http codes should cover the majority of cases.
>>> Links would definitely be allowed
>>> Cheers, >>> Mike
>>> On Mon, Oct 24, 2011 at 11:14 AM, Mark Derricutt <m...@talios.com> wrote: >>> > I assume there would be <link/>'s available inside the <error/> element?
>>> > I think it could be handy, altho I'm not sure about the <code/> element, >>> > is >>> > that intended to be a mirror of the HTTP STATUS CODE returned by a >>> > request, >>> > or a more higher level, application specific error?
>>> > Mark
>>> > -- >>> > "Great artists are extremely selfish and arrogant things" — Steven >>> > Wilson, >>> > Porcupine Tree
>>> > On Mon, Oct 24, 2011 at 10:21 PM, Mike Kelly <mikekelly...@gmail.com> >>> > wrote:
>>> >> What would everyone think about adding some extra bits for error >>> >> responses? Something along the lines of:
I'm not sure that it is worth cluttering up hal with this new element. I can see value in some media type for returning extended error information, but maybe we need a application/vnd.error+xml instead of extending hal. Is there any reason this error media type could not be used for any request regardless of the media type that was being requested?
Is there any benefit other than convenience that it be part of the hal spec?
I guess the only benefit is that bringing in HAL's link element is more complicated if it's split out as a separate media type.
But given that I'm planning on deferring HAL's link element to terminology from Web Linking RFC, handling that in the same way for an error+xml|json media type would not be a big deal.
On reflection, I suspect you may be right that creating a new media type is the best approach.
Darrel do you want to spec/register these types yourself?
On Mon, Oct 24, 2011 at 1:26 PM, Darrel Miller <darrel.mil...@gmail.com> wrote: > I'm not sure that it is worth cluttering up hal with this new element. > I can see value in some media type for returning extended error > information, but maybe we need a application/vnd.error+xml instead of > extending hal. Is there any reason this error media type could not be > used for any request regardless of the media type that was being > requested?
> Is there any benefit other than convenience that it be part of the hal spec?
Just an FYI, the error representation that Mike showed in the initial
message on this thread matches almost exactly with what we're
currently doing - we literally have the same 3 elements (just
different names). We've been somewhat undecided as to whether we're
considering this representation a HAL representation (i.e., extension
of HAL) versus a different but related media type specific to errors
as Darrel mentions. Very interested in other people's opinions on this
topic.
Steve
On Oct 24, 8:26 am, Darrel Miller <darrel.mil...@gmail.com> wrote:
> I'm not sure that it is worth cluttering up hal with this new element.
> I can see value in some media type for returning extended error
> information, but maybe we need a application/vnd.error+xml instead of
> extending hal. Is there any reason this error media type could not be
> used for any request regardless of the media type that was being
> requested?
> Is there any benefit other than convenience that it be part of the hal spec?
I suspect most people have re-invented this wheel at some point or other. Considering RFC2616 says you SHOULD return additional details about an error when you return a 400, having a media type designed specifically for that purpose would seem valuable.
I did create my own media type for returning error information, but recently I've been debating just returning text/plain in the body as I rarely need to communicate more semantics than the HTTP Status code provides. I do appreciate how some clients may need more precise information.
<steve.michelo...@gmail.com> wrote: > Just an FYI, the error representation that Mike showed in the initial > message on this thread matches almost exactly with what we're > currently doing - we literally have the same 3 elements (just > different names). We've been somewhat undecided as to whether we're > considering this representation a HAL representation (i.e., extension > of HAL) versus a different but related media type specific to errors > as Darrel mentions. Very interested in other people's opinions on this > topic.
> Steve
> On Oct 24, 8:26 am, Darrel Miller <darrel.mil...@gmail.com> wrote: >> I'm not sure that it is worth cluttering up hal with this new element. >> I can see value in some media type for returning extended error >> information, but maybe we need a application/vnd.error+xml instead of >> extending hal. Is there any reason this error media type could not be >> used for any request regardless of the media type that was being >> requested?
>> Is there any benefit other than convenience that it be part of the hal spec?
Hey, folks! Just joined. Have recently become very passionate about
REST services in WCF, hypermediathe HAL spec, and Darrel's RESTAgent.
Great stuff, folks! Thank you for contributing, and for making this
discussion open.
Just my (newb) two cents, I dislike the thought of making error
response strongly tied to the spec. It seems like just another media
type to me. I think the needs depend greatly on the implementation,
and so to tie this in to HAL is counter to the purpose.
Best,
David
On Oct 24, 9:27 am, Darrel Miller <darrel.mil...@gmail.com> wrote:
> I suspect most people have re-invented this wheel at some point or
> other. Considering RFC2616 says you SHOULD return additional details
> about an error when you return a 400, having a media type designed
> specifically for that purpose would seem valuable.
> I did create my own media type for returning error information, but
> recently I've been debating just returning text/plain in the body as I
> rarely need to communicate more semantics than the HTTP Status code
> provides. I do appreciate how some clients may need more precise
> information.
> Darrel
> On Mon, Oct 24, 2011 at 8:46 AM, Steve Michelotti
> <steve.michelo...@gmail.com> wrote:
> > Just an FYI, the error representation that Mike showed in the initial
> > message on this thread matches almost exactly with what we're
> > currently doing - we literally have the same 3 elements (just
> > different names). We've been somewhat undecided as to whether we're
> > considering this representation a HAL representation (i.e., extension
> > of HAL) versus a different but related media type specific to errors
> > as Darrel mentions. Very interested in other people's opinions on this
> > topic.
> > Steve
> > On Oct 24, 8:26 am, Darrel Miller <darrel.mil...@gmail.com> wrote:
> >> I'm not sure that it is worth cluttering up hal with this new element.
> >> I can see value in some media type for returning extended error
> >> information, but maybe we need a application/vnd.error+xml instead of
> >> extending hal. Is there any reason this error media type could not be
> >> used for any request regardless of the media type that was being
> >> requested?
> >> Is there any benefit other than convenience that it be part of the hal spec?
Given that HAL is just a spec, does it actually -matter- that this error format it defined as part of the HAL spec itself? In that, even if you're not using HAL for your resources, you -could- use the HAL-error extension format. It's not as tho one mandates the other, or brings along with it implementation baggage.
I somewhat see this similar to the shal extension format I asked about the other day, which adds additional semantics around handling updates to resources, this ehal (error hal?) extension adds error semantics.
Is the error also a representation of the resource? One that happens to currently be in an error state? ( maybe not, just thought dropping before I run off to work ), if so, would something like:
<resource href="/404.html"> <link rel="..." href="..."/> <error id="x" message="Resource was not found"/> </resource>
This leaves links were they are and all other semantics are in place, only we have a new <error/> element, links, but NO embedded resources.
Mark
-- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree
On Tue, Oct 25, 2011 at 4:37 AM, David Barrett <da...@davidbarrett.net>wrote:
> Just my (newb) two cents, I dislike the thought of making error > response strongly tied to the spec. It seems like just another media > type to me. I think the needs depend greatly on the implementation, > and so to tie this in to HAL is counter to the purpose.
The advantage to me of having a distinct media type being able to identify the payload as an error message by looking at the media type. I suppose if you minted application/vnd+ehal+xml to contain errors then my requirement would be met. However, I'm not really sure at this point if the representation has anything to do with hal.
Hal is specifically for providing representations of resources that have URIs. In this case, I'm not sure the representation that is returned necessarily is a resource. I think it is a representation of application state. I don't think it should have it's own distinct URI. The exception of course would be if you logged the error to the database and exposed that as a resource by assigning it a URI. Which is actually a really cool idea actually, but I digress.
I don't think there is a right and wrong way to handle error information. I personally view it as completely distinct from the media type of the resource that I am trying to access and others see benefits in having the capability incorporated into the media type.
I wouldn't mind if someone created an application/vnd.ehal+xml but personally I'd rather use something independent.
On Mon, Oct 24, 2011 at 3:50 PM, Mark Derricutt <m...@talios.com> wrote: > Given that HAL is just a spec, does it actually -matter- that this error > format it defined as part of the HAL spec itself? In that, even if you're > not using HAL for your resources, you -could- use the HAL-error extension > format. It's not as tho one mandates the other, or brings along with it > implementation baggage.
> I somewhat see this similar to the shal extension format I asked about the > other day, which adds additional semantics around handling updates to > resources, this ehal (error hal?) extension adds error semantics.
> Is the error also a representation of the resource? One that happens to > currently be in an error state? ( maybe not, just thought dropping before I > run off to work ), if so, would something like:
> <resource href="/404.html"> > <link rel="..." href="..."/> > <error id="x" message="Resource was not found"/> > </resource>
> This leaves links were they are and all other semantics are in place, only > we have a new <error/> element, links, but NO embedded resources.
On Mon, Oct 24, 2011 at 11:05 PM, Darrel Miller <darrel.mil...@gmail.com> wrote: > The advantage to me of having a distinct media type being able to > identify the payload as an error message by looking at the media type. > I suppose if you minted application/vnd+ehal+xml to contain errors > then my requirement would be met. However, I'm not really sure at > this point if the representation has anything to do with hal.
> Hal is specifically for providing representations of resources that > have URIs. In this case, I'm not sure the representation that is > returned necessarily is a resource. I think it is a representation of > application state. I don't think it should have it's own distinct URI. > The exception of course would be if you logged the error to the > database and exposed that as a resource by assigning it a URI. Which > is actually a really cool idea actually, but I digress.
> I don't think there is a right and wrong way to handle error > information. I personally view it as completely distinct from the > media type of the resource that I am trying to access and others see > benefits in having the capability incorporated into the media type.
> I wouldn't mind if someone created an application/vnd.ehal+xml but > personally I'd rather use something independent.
> Darrel
> On Mon, Oct 24, 2011 at 3:50 PM, Mark Derricutt <m...@talios.com> wrote: >> Given that HAL is just a spec, does it actually -matter- that this error >> format it defined as part of the HAL spec itself? In that, even if you're >> not using HAL for your resources, you -could- use the HAL-error extension >> format. It's not as tho one mandates the other, or brings along with it >> implementation baggage.
>> I somewhat see this similar to the shal extension format I asked about the >> other day, which adds additional semantics around handling updates to >> resources, this ehal (error hal?) extension adds error semantics.
>> Is the error also a representation of the resource? One that happens to >> currently be in an error state? ( maybe not, just thought dropping before I >> run off to work ), if so, would something like:
>> <resource href="/404.html"> >> <link rel="..." href="..."/> >> <error id="x" message="Resource was not found"/> >> </resource>
>> This leaves links were they are and all other semantics are in place, only >> we have a new <error/> element, links, but NO embedded resources.
first, the response code should the be way clients learn if there was an error in processing the request (4x, 5x)
if you want to return error details in the body of a response, one way to do it is to include a single <resource /> element that has an href pointing to the details. maybe a <link /> element is more appropriate, not sure. you could mark this w/ a @rel="error" (or whatever details you like). or, if you want to return errors details directly, just include them as an inline resource w/ type=-"text/plain" or whatever.
Finally, if there is no desire the include an "error-response" of any kind in the HAL media type, i would suggest simply leaving that "out of the spec" all together; defer the whole "error response body" details to some other spec/place. if someone wants to define a new media type just for errors, then your spec will be ready to support it via a <link />, right?
On Mon, Oct 24, 2011 at 18:05, Darrel Miller <darrel.mil...@gmail.com> wrote: > The advantage to me of having a distinct media type being able to > identify the payload as an error message by looking at the media type. > I suppose if you minted application/vnd+ehal+xml to contain errors > then my requirement would be met. However, I'm not really sure at > this point if the representation has anything to do with hal.
> Hal is specifically for providing representations of resources that > have URIs. In this case, I'm not sure the representation that is > returned necessarily is a resource. I think it is a representation of > application state. I don't think it should have it's own distinct URI. > The exception of course would be if you logged the error to the > database and exposed that as a resource by assigning it a URI. Which > is actually a really cool idea actually, but I digress.
> I don't think there is a right and wrong way to handle error > information. I personally view it as completely distinct from the > media type of the resource that I am trying to access and others see > benefits in having the capability incorporated into the media type.
> I wouldn't mind if someone created an application/vnd.ehal+xml but > personally I'd rather use something independent.
> Darrel
> On Mon, Oct 24, 2011 at 3:50 PM, Mark Derricutt <m...@talios.com> wrote: >> Given that HAL is just a spec, does it actually -matter- that this error >> format it defined as part of the HAL spec itself? In that, even if you're >> not using HAL for your resources, you -could- use the HAL-error extension >> format. It's not as tho one mandates the other, or brings along with it >> implementation baggage.
>> I somewhat see this similar to the shal extension format I asked about the >> other day, which adds additional semantics around handling updates to >> resources, this ehal (error hal?) extension adds error semantics.
>> Is the error also a representation of the resource? One that happens to >> currently be in an error state? ( maybe not, just thought dropping before I >> run off to work ), if so, would something like:
>> <resource href="/404.html"> >> <link rel="..." href="..."/> >> <error id="x" message="Resource was not found"/> >> </resource>
>> This leaves links were they are and all other semantics are in place, only >> we have a new <error/> element, links, but NO embedded resources.
On Mon, Oct 24, 2011 at 11:24 PM, mca <m...@amundsen.com> wrote: > some comments:
> first, the response code should the be way clients learn if there was > an error in processing the request (4x, 5x)
right, this wouldn't be intended to change that, it's just a generic type for representing errors (in those 4xx/5xx responses).
> if you want to return error details in the body of a response, one way > to do it is to include a single <resource /> element that has an href > pointing to the details. maybe a <link /> element is more appropriate, > not sure. you could mark this w/ a @rel="error" (or whatever details > you like). > or, if you want to return errors details directly, just include them > as an inline resource w/ type=-"text/plain" or whatever.
error responses aren't representations of a resource's state, they're representations of a failure state produced by an intermediary process of some kind.
It doesn't feel right to use hal in responses that don't actually represent resource state.
> Finally, if there is no desire the include an "error-response" of any > kind in the HAL media type, i would suggest simply leaving that "out > of the spec" all together; defer the whole "error response body" > details to some other spec/place. if someone wants to define a new > media type just for errors, then your spec will be ready to support it > via a <link />, right?
I'm hoping to spec this out myself, I will add a note of some kind to the HAL spec suggesting it can be used
Is it ok (per HTTP) to return body of media-type 'application/vnd+error+xml' in case of failure (4xx/5xx), even though client has given only one media-type of 'application/vnd.hal+xml' in accept header?
On Monday, 27 February 2012 19:41:55 UTC, Shahzaib Younis wrote:
> Is it ok (per HTTP) to return body of media-type 'application/vnd+error+xml' > in case of failure (4xx/5xx), even though client has given only one > media-type of 'application/vnd.hal+xml' in accept header?
In theory if the client has not expressed its willingness to accept the application/vnd.error+xml mime type as a response and you cannot return application/hal+xml, then you CAN return a different type (or you can return a 406). From RFC2616:
"Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable."
Please feed back if you have comments (i'd suggest not via this discussion as this is specifically about HAL and this has been created as something separate).
I know this is an old thread, but was a consensus reached? Is the spec mentioned below (or some other error media type) the best approach or would something like this work just fine?
<resource> ... my random properties in here I define and document as an error for my API ... ? </resource>
> Please feed back if you have comments (i'd suggest not via this discussion > as this is specifically about HAL and this has been created as something > separate).
Unless the error response actually represents the state of some
resource, then it probably doesn't make sense to use hal there. Having
said that I could see why haivng hal's links and embedded resources at
hand in the response would be good.
<error>
<link ... />
...
...
...
</error>
Not sure what's out there for xml right now, if worst came to worst
you could always just create your own media type for this and
reference the bits out of hal that you want to borrow.
We should probably write up hal+xml as an I-D at some point in the
near future too, thanks for reminding me! :)
On Sun, Sep 30, 2012 at 4:06 AM, Luke Stokes <luke.sto...@gmail.com> wrote:
> I know this is an old thread, but was a consensus reached? Is the spec
> mentioned below (or some other error media type) the best approach or would
> something like this work just fine?
> <resource>
> ... my random properties in here I define and document as an error for my
> API ... ?
> </resource>
> Thanks :)
> On Tuesday, April 24, 2012 2:35:57 PM UTC-5, blongden wrote:
>> Please feed back if you have comments (i'd suggest not via this discussion
>> as this is specifically about HAL and this has been created as something
>> separate).
Thanks Mike. We were looking to go with Siren but have some clients who need XML so we're going to start with HAL (also since we're almost exactly there already). We'll probably add Siren shortly after that. Feels nice to ditch all the custom code I had for outputting custom vendor specific media types. :)
More details on the XML spec would be helpful. I'll keep an eye out for a standard error media type, but most likely we'll roll our own. Thanks again.
On Sunday, September 30, 2012 1:21:33 PM UTC-5, Mike Kelly wrote:
> Hi Luke,
> Unless the error response actually represents the state of some > resource, then it probably doesn't make sense to use hal there. Having > said that I could see why haivng hal's links and embedded resources at > hand in the response would be good.
> Not sure what's out there for xml right now, if worst came to worst > you could always just create your own media type for this and > reference the bits out of hal that you want to borrow.
> We should probably write up hal+xml as an I-D at some point in the > near future too, thanks for reminding me! :)
> Cheers, > M
> On Sun, Sep 30, 2012 at 4:06 AM, Luke Stokes <luke....@gmail.com<javascript:>> > wrote: > > I know this is an old thread, but was a consensus reached? Is the spec > > mentioned below (or some other error media type) the best approach or > would > > something like this work just fine?
> > <resource> > > ... my random properties in here I define and document as an error for > my > > API ... ? > > </resource>
> > Thanks :)
> > On Tuesday, April 24, 2012 2:35:57 PM UTC-5, blongden wrote:
> >> Please feed back if you have comments (i'd suggest not via this > discussion > >> as this is specifically about HAL and this has been created as > something > >> separate).
vnd.error+xml and json are still in draft status. It's gained a few users to far and there is a PHP library to build it. I'm intending on writing it up as a 'real' specification once it's had some real world use and can capture all the use cases for an error representation, and so far it's holding up pretty well.
> Unless the error response actually represents the state of some
> resource, then it probably doesn't make sense to use hal there. Having
> said that I could see why haivng hal's links and embedded resources at
> hand in the response would be good.
> Not sure what's out there for xml right now, if worst came to worst
> you could always just create your own media type for this and
> reference the bits out of hal that you want to borrow.
> We should probably write up hal+xml as an I-D at some point in the
> near future too, thanks for reminding me! :)
> Cheers,
> M
> On Sun, Sep 30, 2012 at 4:06 AM, Luke Stokes <luke.sto...@gmail.com> wrote:
>> I know this is an old thread, but was a consensus reached? Is the spec
>> mentioned below (or some other error media type) the best approach or would
>> something like this work just fine?
>> <resource>
>> ... my random properties in here I define and document as an error for my
>> API ... ?
>> </resource>
>> Thanks :)
>> On Tuesday, April 24, 2012 2:35:57 PM UTC-5, blongden wrote:
>>> Please feed back if you have comments (i'd suggest not via this discussion
>>> as this is specifically about HAL and this has been created as something
>>> separate).
