[API] What should happen if ...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[API] What should happen if ...

JOSE MANUEL CANTERA FONSECA

If a "not making sense" (aspect, property) combination (being 'aspect' and 'property' two recognized elements of a vocabulary) is used for invoking the API, example
 
Service.getPropertyValue('http://www.w3.org/2008/01/ddr-core-vocabulary', 'webBrowser', 'inputDevices');
 
Possibilties:
 
a) NOT_KNOWN exception thrown
b) Aspect not recognized exception thrown, however the aspect actually is a valid aspect for that vocabulary
c) Property not recognized exception thrown, however the property actually is a valid property for that vocabulary
 
I'm more inclined to say a), however the point is that the combination of aspect & property is not a valid (legal), according to the DDR Core Vocabulary.
 
I think that an implementation should throw a NAME_EXCEPTION with an error code saying "Aspect, Property combination not valid"
 
What do others think?
 
Best Regards
Reply | Threaded
Open this post in threaded view
|

Re: [API] What should happen if ...

Rafael Casero
For me makes sense c) because property is not recognized in the subset defined by all the properties that an aspect has, but a) is Ok too.

Raf.Casero

-------- Mensaje Original --------
If a "not making sense" (aspect, property) combination (being 'aspect' and 'property' two recognized elements of a vocabulary) is used for invoking the API, example
 
Service.getPropertyValue('http://www.w3.org/2008/01/ddr-core-vocabulary', 'webBrowser', 'inputDevices');
 
Possibilties:
 
a) NOT_KNOWN exception thrown
b) Aspect not recognized exception thrown, however the aspect actually is a valid aspect for that vocabulary
c) Property not recognized exception thrown, however the property actually is a valid property for that vocabulary
 
I'm more inclined to say a), however the point is that the combination of aspect & property is not a valid (legal), according to the DDR Core Vocabulary.
 
I think that an implementation should throw a NAME_EXCEPTION with an error code saying "Aspect, Property combination not valid"
 
What do others think?
 
Best Regards
Reply | Threaded
Open this post in threaded view
|

RE: [API] What should happen if ...

Rotan Hanrahan

We defined the method getPropertyValue(...) to throw a NameException. The spec also allows it to throw a SystemException but that would not be appropriate in this case. The "name" in this case is a compound, just like having a first name and a family name. If you do not use the right parts of the compound name, then you are not properly identifying something. You are either identifying something else, or you are not identifying anything at all.
 
"Not Known" is a different issue. This is a situation where a property has been correctly identified (by its local name and associated aspect) but there is no data to go with that property. In this case, it is the property value that is not known (emphasis: the property *is* known, it is the *property value* that is not known). You will get a ValueException with code NOT_KNOWN if you try to use a value of a property that is not known, but you can avoid this exception by first testing to see if the value exists in the repository, using the exists() method.
 
In the example, José has not named anything that is understood by the implementation. The particular implementation I assume knows the Core Vocabulary, and nothing in that vocabulary matches "webBrowser & inputDevices". So in this case the problem is in identification (i.e. naming) so the correct exception to throw is a NameException. We assume that in this example the vocabulary *is* known, so the exception code will not be VOCABULARY_NOT_RECOGNISED. That leaves two possible remaining codes:
  PROPERTY_NOT_RECOGNISED
and
  ASPECT_NOT_RECOGNISED
 
This then leads to the real problem, which has been identified in José's original message: which of these two codes is the more appropriate? We do have a third option, because (as mentioned in section 4.4.4) we are not obliged to actually set the code, so in theory we could set no code. The issue is that none of the codes that are associated with a NameException actually identify the particular case where both the property name and aspect are valid, but not their combination. This does not prevent the throwing of the exception, nor does it prevent us from dealing with this general case, which is that a valid Property has not been identified. If an implementation is sensitive to such detail in the exception, then the specification permits further refinement through additional codes.
 
To further complicate matters, consider the VOCABULAR_NOT_RECOGNISED code again. The actual cause of the error might be with the choice of vocabulary. Perhaps in an alternative vocabulary the combination of local property name and aspect name would be valid. The safest interpretation is that none of the three possible codes are strictly appropriate insofar as it is not necessarily clear what is the root cause of the exception. Therefore throw an exception *without* a particular code, but (as the specification clearly says) include appropriate explanation in the accompanying diagnostic message.
 
---Rotan.

________________________________

From: [hidden email] on behalf of Rafael Casero
Sent: Mon 02/06/2008 17:33
To: [hidden email]
Cc: JOSE MANUEL CANTERA FONSECA
Subject: Re: [API] What should happen if ...


For me makes sense c) because property is not recognized in the subset defined by all the properties that an aspect has, but a) is Ok too.

Raf.Casero

-------- Mensaje Original --------

        If a "not making sense" (aspect, property) combination (being 'aspect' and 'property' two recognized elements of a vocabulary) is used for invoking the API, example
         
        Service.getPropertyValue('http://www.w3.org/2008/01/ddr-core-vocabulary', 'webBrowser', 'inputDevices');
         
        Possibilties:
         
        a) NOT_KNOWN exception thrown
        b) Aspect not recognized exception thrown, however the aspect actually is a valid aspect for that vocabulary
        c) Property not recognized exception thrown, however the property actually is a valid property for that vocabulary
         
        I'm more inclined to say a), however the point is that the combination of aspect & property is not a valid (legal), according to the DDR Core Vocabulary.
         
        I think that an implementation should throw a NAME_EXCEPTION with an error code saying "Aspect, Property combination not valid"
         
        What do others think?
         
        Best Regards


Reply | Threaded
Open this post in threaded view
|

RE: [API] What should happen if ...

JOSE MANUEL CANTERA FONSECA

I agree with you Rotan, maybe we are a bit late to add a new exception code to the spec, however we can do it in our implementation

Best Regards

-----Mensaje original-----
De: Rotan Hanrahan [mailto:[hidden email]]
Enviado el: lunes, 02 de junio de 2008 21:53
Para: Rafael Casero; [hidden email]
CC: JOSE MANUEL CANTERA FONSECA
Asunto: RE: [API] What should happen if ...

We defined the method getPropertyValue(...) to throw a NameException. The spec also allows it to throw a SystemException but that would not be appropriate in this case. The "name" in this case is a compound, just like having a first name and a family name. If you do not use the right parts of the compound name, then you are not properly identifying something. You are either identifying something else, or you are not identifying anything at all.

"Not Known" is a different issue. This is a situation where a property has been correctly identified (by its local name and associated aspect) but there is no data to go with that property. In this case, it is the property value that is not known (emphasis: the property *is* known, it is the *property value* that is not known). You will get a ValueException with code NOT_KNOWN if you try to use a value of a property that is not known, but you can avoid this exception by first testing to see if the value exists in the repository, using the exists() method.

In the example, José has not named anything that is understood by the implementation. The particular implementation I assume knows the Core Vocabulary, and nothing in that vocabulary matches "webBrowser & inputDevices". So in this case the problem is in identification (i.e. naming) so the correct exception to throw is a NameException. We assume that in this example the vocabulary *is* known, so the exception code will not be VOCABULARY_NOT_RECOGNISED. That leaves two possible remaining codes:
  PROPERTY_NOT_RECOGNISED
and
  ASPECT_NOT_RECOGNISED

This then leads to the real problem, which has been identified in José's original message: which of these two codes is the more appropriate? We do have a third option, because (as mentioned in section 4.4.4) we are not obliged to actually set the code, so in theory we could set no code. The issue is that none of the codes that are associated with a NameException actually identify the particular case where both the property name and aspect are valid, but not their combination. This does not prevent the throwing of the exception, nor does it prevent us from dealing with this general case, which is that a valid Property has not been identified. If an implementation is sensitive to such detail in the exception, then the specification permits further refinement through additional codes.

To further complicate matters, consider the VOCABULAR_NOT_RECOGNISED code again. The actual cause of the error might be with the choice of vocabulary. Perhaps in an alternative vocabulary the combination of local property name and aspect name would be valid. The safest interpretation is that none of the three possible codes are strictly appropriate insofar as it is not necessarily clear what is the root cause of the exception. Therefore throw an exception *without* a particular code, but (as the specification clearly says) include appropriate explanation in the accompanying diagnostic message.

---Rotan.

________________________________

From: [hidden email] on behalf of Rafael Casero
Sent: Mon 02/06/2008 17:33
To: [hidden email]
Cc: JOSE MANUEL CANTERA FONSECA
Subject: Re: [API] What should happen if ...


For me makes sense c) because property is not recognized in the subset defined by all the properties that an aspect has, but a) is Ok too.

Raf.Casero

-------- Mensaje Original --------

        If a "not making sense" (aspect, property) combination (being 'aspect' and 'property' two recognized elements of a vocabulary) is used for invoking the API, example

        Service.getPropertyValue('http://www.w3.org/2008/01/ddr-core-vocabulary', 'webBrowser', 'inputDevices');

        Possibilties:

        a) NOT_KNOWN exception thrown
        b) Aspect not recognized exception thrown, however the aspect actually is a valid aspect for that vocabulary
        c) Property not recognized exception thrown, however the property actually is a valid property for that vocabulary

        I'm more inclined to say a), however the point is that the combination of aspect & property is not a valid (legal), according to the DDR Core Vocabulary.

        I think that an implementation should throw a NAME_EXCEPTION with an error code saying "Aspect, Property combination not valid"

        What do others think?

        Best Regards


Reply | Threaded
Open this post in threaded view
|

Re: [API] What should happen if ...

Jo Rabin-2

My understanding is that a fully spelled out property identifier has a
vocab, an aspect and a localPropertyName. Effectively the vocab and
aspect namespace the localPropertyName so it is appropriate to throw a
PROPERTY_NOT_KNOWN in the case where the vocabulary and aspect are known
but the localPropertyName does not exist within that namespace.

As far as I know, we don't spell out that localPropertyNames of
different aspects MUST be the same if they refer to the same thing, nor
that they MUST be different if they don't. We did construct this system
so that "vendor" when used as a localPropertyName in different aspects,
COULD have the same meaning.

So to say that a localPropertyName does exist but not for the given
aspect is taking the logic of our system of vocabularies too far, in my
view. This is the "Simple API" and one of the aspects of simplicity is
that we chose not to spell this matter out.

I believe that an extension to our system would introduce the idea of
"term". A "term" would be a term of the vocabulary, not a name in an
aspect. In this case it would be right to have an additional exception
ASPECT_DOES_NOT_HAVE_TERM (or something). But as we have it today, where
a localPropertyname is indeed local to the Aspect I think that
PROPERTY_NOT_RECOGNIZED is correct.

Jo



On 03/06/2008 08:11, JOSE MANUEL CANTERA FONSECA wrote:

> I agree with you Rotan, maybe we are a bit late to add a new exception code to the spec, however we can do it in our implementation
>
> Best Regards
>
> -----Mensaje original-----
> De: Rotan Hanrahan [mailto:[hidden email]]
> Enviado el: lunes, 02 de junio de 2008 21:53
> Para: Rafael Casero; [hidden email]
> CC: JOSE MANUEL CANTERA FONSECA
> Asunto: RE: [API] What should happen if ...
>
> We defined the method getPropertyValue(...) to throw a NameException. The spec also allows it to throw a SystemException but that would not be appropriate in this case. The "name" in this case is a compound, just like having a first name and a family name. If you do not use the right parts of the compound name, then you are not properly identifying something. You are either identifying something else, or you are not identifying anything at all.
>
> "Not Known" is a different issue. This is a situation where a property has been correctly identified (by its local name and associated aspect) but there is no data to go with that property. In this case, it is the property value that is not known (emphasis: the property *is* known, it is the *property value* that is not known). You will get a ValueException with code NOT_KNOWN if you try to use a value of a property that is not known, but you can avoid this exception by first testing to see if the value exists in the repository, using the exists() method.
>
> In the example, José has not named anything that is understood by the implementation. The particular implementation I assume knows the Core Vocabulary, and nothing in that vocabulary matches "webBrowser & inputDevices". So in this case the problem is in identification (i.e. naming) so the correct exception to throw is a NameException. We assume that in this example the vocabulary *is* known, so the exception code will not be VOCABULARY_NOT_RECOGNISED. That leaves two possible remaining codes:
>   PROPERTY_NOT_RECOGNISED
> and
>   ASPECT_NOT_RECOGNISED
>
> This then leads to the real problem, which has been identified in José's original message: which of these two codes is the more appropriate? We do have a third option, because (as mentioned in section 4.4.4) we are not obliged to actually set the code, so in theory we could set no code. The issue is that none of the codes that are associated with a NameException actually identify the particular case where both the property name and aspect are valid, but not their combination. This does not prevent the throwing of the exception, nor does it prevent us from dealing with this general case, which is that a valid Property has not been identified. If an implementation is sensitive to such detail in the exception, then the specification permits further refinement through additional codes.
>
> To further complicate matters, consider the VOCABULAR_NOT_RECOGNISED code again. The actual cause of the error might be with the choice of vocabulary. Perhaps in an alternative vocabulary the combination of local property name and aspect name would be valid. The safest interpretation is that none of the three possible codes are strictly appropriate insofar as it is not necessarily clear what is the root cause of the exception. Therefore throw an exception *without* a particular code, but (as the specification clearly says) include appropriate explanation in the accompanying diagnostic message.
>
> ---Rotan.
>
> ________________________________
>
> From: [hidden email] on behalf of Rafael Casero
> Sent: Mon 02/06/2008 17:33
> To: [hidden email]
> Cc: JOSE MANUEL CANTERA FONSECA
> Subject: Re: [API] What should happen if ...
>
>
> For me makes sense c) because property is not recognized in the subset defined by all the properties that an aspect has, but a) is Ok too.
>
> Raf.Casero
>
> -------- Mensaje Original --------
>
>         If a "not making sense" (aspect, property) combination (being 'aspect' and 'property' two recognized elements of a vocabulary) is used for invoking the API, example
>
>         Service.getPropertyValue('http://www.w3.org/2008/01/ddr-core-vocabulary', 'webBrowser', 'inputDevices');
>
>         Possibilties:
>
>         a) NOT_KNOWN exception thrown
>         b) Aspect not recognized exception thrown, however the aspect actually is a valid aspect for that vocabulary
>         c) Property not recognized exception thrown, however the property actually is a valid property for that vocabulary
>
>         I'm more inclined to say a), however the point is that the combination of aspect & property is not a valid (legal), according to the DDR Core Vocabulary.
>
>         I think that an implementation should throw a NAME_EXCEPTION with an error code saying "Aspect, Property combination not valid"
>
>         What do others think?
>
>         Best Regards
>
>

Reply | Threaded
Open this post in threaded view
|

RE: [API] What should happen if ...

JOSE MANUEL CANTERA FONSECA

I don't agree. If you consider triples (vocabulary,aspect,localpropertyName) as "properties" then every time a property, aspect or vocabulary is not recognized you will receive a property not recognized exception code, which it is not correct. I prefer to say explicitly that the combination of the three things is not legal, and avoiding other complications or "particular interpretations" of what a property is

Best Regards

________________________________________
De: [hidden email] [[hidden email]] En nombre de Jo Rabin [[hidden email]]
Enviado el: martes, 03 de junio de 2008 10:23
Para: [hidden email]
Asunto: Re: [API] What should happen if ...

My understanding is that a fully spelled out property identifier has a
vocab, an aspect and a localPropertyName. Effectively the vocab and
aspect namespace the localPropertyName so it is appropriate to throw a
PROPERTY_NOT_KNOWN in the case where the vocabulary and aspect are known
but the localPropertyName does not exist within that namespace.

As far as I know, we don't spell out that localPropertyNames of
different aspects MUST be the same if they refer to the same thing, nor
that they MUST be different if they don't. We did construct this system
so that "vendor" when used as a localPropertyName in different aspects,
COULD have the same meaning.

So to say that a localPropertyName does exist but not for the given
aspect is taking the logic of our system of vocabularies too far, in my
view. This is the "Simple API" and one of the aspects of simplicity is
that we chose not to spell this matter out.

I believe that an extension to our system would introduce the idea of
"term". A "term" would be a term of the vocabulary, not a name in an
aspect. In this case it would be right to have an additional exception
ASPECT_DOES_NOT_HAVE_TERM (or something). But as we have it today, where
a localPropertyname is indeed local to the Aspect I think that
PROPERTY_NOT_RECOGNIZED is correct.

Jo



On 03/06/2008 08:11, JOSE MANUEL CANTERA FONSECA wrote:

> I agree with you Rotan, maybe we are a bit late to add a new exception code to the spec, however we can do it in our implementation
>
> Best Regards
>
> -----Mensaje original-----
> De: Rotan Hanrahan [mailto:[hidden email]]
> Enviado el: lunes, 02 de junio de 2008 21:53
> Para: Rafael Casero; [hidden email]
> CC: JOSE MANUEL CANTERA FONSECA
> Asunto: RE: [API] What should happen if ...
>
> We defined the method getPropertyValue(...) to throw a NameException. The spec also allows it to throw a SystemException but that would not be appropriate in this case. The "name" in this case is a compound, just like having a first name and a family name. If you do not use the right parts of the compound name, then you are not properly identifying something. You are either identifying something else, or you are not identifying anything at all.
>
> "Not Known" is a different issue. This is a situation where a property has been correctly identified (by its local name and associated aspect) but there is no data to go with that property. In this case, it is the property value that is not known (emphasis: the property *is* known, it is the *property value* that is not known). You will get a ValueException with code NOT_KNOWN if you try to use a value of a property that is not known, but you can avoid this exception by first testing to see if the value exists in the repository, using the exists() method.
>
> In the example, José has not named anything that is understood by the implementation. The particular implementation I assume knows the Core Vocabulary, and nothing in that vocabulary matches "webBrowser & inputDevices". So in this case the problem is in identification (i.e. naming) so the correct exception to throw is a NameException. We assume that in this example the vocabulary *is* known, so the exception code will not be VOCABULARY_NOT_RECOGNISED. That leaves two possible remaining codes:
>   PROPERTY_NOT_RECOGNISED
> and
>   ASPECT_NOT_RECOGNISED
>
> This then leads to the real problem, which has been identified in José's original message: which of these two codes is the more appropriate? We do have a third option, because (as mentioned in section 4.4.4) we are not obliged to actually set the code, so in theory we could set no code. The issue is that none of the codes that are associated with a NameException actually identify the particular case where both the property name and aspect are valid, but not their combination. This does not prevent the throwing of the exception, nor does it prevent us from dealing with this general case, which is that a valid Property has not been identified. If an implementation is sensitive to such detail in the exception, then the specification permits further refinement through additional codes.
>
> To further complicate matters, consider the VOCABULAR_NOT_RECOGNISED code again. The actual cause of the error might be with the choice of vocabulary. Perhaps in an alternative vocabulary the combination of local property name and aspect name would be valid. The safest interpretation is that none of the three possible codes are strictly appropriate insofar as it is not necessarily clear what is the root cause of the exception. Therefore throw an exception *without* a particular code, but (as the specification clearly says) include appropriate explanation in the accompanying diagnostic message.
>
> ---Rotan.
>
> ________________________________
>
> From: [hidden email] on behalf of Rafael Casero
> Sent: Mon 02/06/2008 17:33
> To: [hidden email]
> Cc: JOSE MANUEL CANTERA FONSECA
> Subject: Re: [API] What should happen if ...
>
>
> For me makes sense c) because property is not recognized in the subset defined by all the properties that an aspect has, but a) is Ok too.
>
> Raf.Casero
>
> -------- Mensaje Original --------
>
>         If a "not making sense" (aspect, property) combination (being 'aspect' and 'property' two recognized elements of a vocabulary) is used for invoking the API, example
>
>         Service.getPropertyValue('http://www.w3.org/2008/01/ddr-core-vocabulary', 'webBrowser', 'inputDevices');
>
>         Possibilties:
>
>         a) NOT_KNOWN exception thrown
>         b) Aspect not recognized exception thrown, however the aspect actually is a valid aspect for that vocabulary
>         c) Property not recognized exception thrown, however the property actually is a valid property for that vocabulary
>
>         I'm more inclined to say a), however the point is that the combination of aspect & property is not a valid (legal), according to the DDR Core Vocabulary.
>
>         I think that an implementation should throw a NAME_EXCEPTION with an error code saying "Aspect, Property combination not valid"
>
>         What do others think?
>
>         Best Regards
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [API] What should happen if ...

Jo Rabin-2

I don't think your conclusion follows from what I said, though I agree
that mine is one of several possible perspectives. My understanding is
that for a fully qualified property, validation can proceed as follows:

If the vocabulary is not recognised -> throw a VOCABULARY_NOT_RECOGNIZED
If the Aspect is not known in the vocabulary - > throw a
ASPECT_NOT_RECOGNIZED
If the localPropertyName is not known in the aspect -> throw a
PROPERTY_NOT_RECOGNIZED

If you choose to do it some other way, and of course you're free to,
then for consistency's sake you might take the view that you recognise
that an aspect exists in some other vocabulary and throw an
INVALID_COMBINATION error. Equally, if, say, both the aspectName and the
localPropertyName are in error then you need to choose which to identify
as the error you are reporting, or yet again report a non-standard
combination error.

I'm satisfied that this is not going to cause interoperability problems
whichever way it is done.

Jo

On 03/06/2008 09:53, JOSE MANUEL CANTERA FONSECA wrote:

> I don't agree. If you consider triples (vocabulary,aspect,localpropertyName) as "properties" then every time a property, aspect or vocabulary is not recognized you will receive a property not recognized exception code, which it is not correct. I prefer to say explicitly that the combination of the three things is not legal, and avoiding other complications or "particular interpretations" of what a property is
>
> Best Regards
>
> ________________________________________
> De: [hidden email] [[hidden email]] En nombre de Jo Rabin [[hidden email]]
> Enviado el: martes, 03 de junio de 2008 10:23
> Para: [hidden email]
> Asunto: Re: [API] What should happen if ...
>
> My understanding is that a fully spelled out property identifier has a
> vocab, an aspect and a localPropertyName. Effectively the vocab and
> aspect namespace the localPropertyName so it is appropriate to throw a
> PROPERTY_NOT_KNOWN in the case where the vocabulary and aspect are known
> but the localPropertyName does not exist within that namespace.
>
> As far as I know, we don't spell out that localPropertyNames of
> different aspects MUST be the same if they refer to the same thing, nor
> that they MUST be different if they don't. We did construct this system
> so that "vendor" when used as a localPropertyName in different aspects,
> COULD have the same meaning.
>
> So to say that a localPropertyName does exist but not for the given
> aspect is taking the logic of our system of vocabularies too far, in my
> view. This is the "Simple API" and one of the aspects of simplicity is
> that we chose not to spell this matter out.
>
> I believe that an extension to our system would introduce the idea of
> "term". A "term" would be a term of the vocabulary, not a name in an
> aspect. In this case it would be right to have an additional exception
> ASPECT_DOES_NOT_HAVE_TERM (or something). But as we have it today, where
> a localPropertyname is indeed local to the Aspect I think that
> PROPERTY_NOT_RECOGNIZED is correct.
>
> Jo
>
>
>
> On 03/06/2008 08:11, JOSE MANUEL CANTERA FONSECA wrote:
>> I agree with you Rotan, maybe we are a bit late to add a new exception code to the spec, however we can do it in our implementation
>>
>> Best Regards
>>
>> -----Mensaje original-----
>> De: Rotan Hanrahan [mailto:[hidden email]]
>> Enviado el: lunes, 02 de junio de 2008 21:53
>> Para: Rafael Casero; [hidden email]
>> CC: JOSE MANUEL CANTERA FONSECA
>> Asunto: RE: [API] What should happen if ...
>>
>> We defined the method getPropertyValue(...) to throw a NameException. The spec also allows it to throw a SystemException but that would not be appropriate in this case. The "name" in this case is a compound, just like having a first name and a family name. If you do not use the right parts of the compound name, then you are not properly identifying something. You are either identifying something else, or you are not identifying anything at all.
>>
>> "Not Known" is a different issue. This is a situation where a property has been correctly identified (by its local name and associated aspect) but there is no data to go with that property. In this case, it is the property value that is not known (emphasis: the property *is* known, it is the *property value* that is not known). You will get a ValueException with code NOT_KNOWN if you try to use a value of a property that is not known, but you can avoid this exception by first testing to see if the value exists in the repository, using the exists() method.
>>
>> In the example, José has not named anything that is understood by the implementation. The particular implementation I assume knows the Core Vocabulary, and nothing in that vocabulary matches "webBrowser & inputDevices". So in this case the problem is in identification (i.e. naming) so the correct exception to throw is a NameException. We assume that in this example the vocabulary *is* known, so the exception code will not be VOCABULARY_NOT_RECOGNISED. That leaves two possible remaining codes:
>>   PROPERTY_NOT_RECOGNISED
>> and
>>   ASPECT_NOT_RECOGNISED
>>
>> This then leads to the real problem, which has been identified in José's original message: which of these two codes is the more appropriate? We do have a third option, because (as mentioned in section 4.4.4) we are not obliged to actually set the code, so in theory we could set no code. The issue is that none of the codes that are associated with a NameException actually identify the particular case where both the property name and aspect are valid, but not their combination. This does not prevent the throwing of the exception, nor does it prevent us from dealing with this general case, which is that a valid Property has not been identified. If an implementation is sensitive to such detail in the exception, then the specification permits further refinement through additional codes.
>>
>> To further complicate matters, consider the VOCABULAR_NOT_RECOGNISED code again. The actual cause of the error might be with the choice of vocabulary. Perhaps in an alternative vocabulary the combination of local property name and aspect name would be valid. The safest interpretation is that none of the three possible codes are strictly appropriate insofar as it is not necessarily clear what is the root cause of the exception. Therefore throw an exception *without* a particular code, but (as the specification clearly says) include appropriate explanation in the accompanying diagnostic message.
>>
>> ---Rotan.
>>
>> ________________________________
>>
>> From: [hidden email] on behalf of Rafael Casero
>> Sent: Mon 02/06/2008 17:33
>> To: [hidden email]
>> Cc: JOSE MANUEL CANTERA FONSECA
>> Subject: Re: [API] What should happen if ...
>>
>>
>> For me makes sense c) because property is not recognized in the subset defined by all the properties that an aspect has, but a) is Ok too.
>>
>> Raf.Casero
>>
>> -------- Mensaje Original --------
>>
>>         If a "not making sense" (aspect, property) combination (being 'aspect' and 'property' two recognized elements of a vocabulary) is used for invoking the API, example
>>
>>         Service.getPropertyValue('http://www.w3.org/2008/01/ddr-core-vocabulary', 'webBrowser', 'inputDevices');
>>
>>         Possibilties:
>>
>>         a) NOT_KNOWN exception thrown
>>         b) Aspect not recognized exception thrown, however the aspect actually is a valid aspect for that vocabulary
>>         c) Property not recognized exception thrown, however the property actually is a valid property for that vocabulary
>>
>>         I'm more inclined to say a), however the point is that the combination of aspect & property is not a valid (legal), according to the DDR Core Vocabulary.
>>
>>         I think that an implementation should throw a NAME_EXCEPTION with an error code saying "Aspect, Property combination not valid"
>>
>>         What do others think?
>>
>>         Best Regards
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

RE: [API] What should happen if ...

Rotan Hanrahan

Let's just be clear, we are not disagreeing about what exception should be thrown. In all cases, a NameException is to be thrown, and this is indicated in the specification. What is causing a little confusion is how the ultimate cause of the exception is to be reported. We have a dual mechanism for such reporting: a code with defined values for specific circumstances, and a diagnostic message to assist developers. There are cases, such as the one presented by José, where the "ultimate cause" is not necessarily clear. As Jo indicates, an individual implementation is free to examine the situation in whatever way it chooses, and to report an ultimate cause as a result of that investigation. Indeed, the algorithm he presents is just one of many possible.

Furthermore, even my own approach is valid, where I refuse to return a specific code because it is not necessarily clear that any of the given codes is guaranteed to represent the actual cause. (I follow the guideline: "better not to direct, rather than mis-direct").

Regardless of how individual implementations attempt to qualify the cause of the exception, it is only of concern for interoperability that the same circumstances of exceptions will lead to the throwing of the same exception, in this case a NameException. Using the gradual refinement (Vocab (Aspect (Property))) suggested by Jo as a means of narrowing in on a root cause for the exception is certainly a valid approach, though not unique.

I'm happy that for a Simple API, this will not be a great issue.

---Rotan.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jo Rabin
Sent: 03 June 2008 10:13
To: [hidden email]
Subject: Re: [API] What should happen if ...


I don't think your conclusion follows from what I said, though I agree
that mine is one of several possible perspectives. My understanding is
that for a fully qualified property, validation can proceed as follows:

If the vocabulary is not recognised -> throw a VOCABULARY_NOT_RECOGNIZED
If the Aspect is not known in the vocabulary - > throw a
ASPECT_NOT_RECOGNIZED
If the localPropertyName is not known in the aspect -> throw a
PROPERTY_NOT_RECOGNIZED

If you choose to do it some other way, and of course you're free to,
then for consistency's sake you might take the view that you recognise
that an aspect exists in some other vocabulary and throw an
INVALID_COMBINATION error. Equally, if, say, both the aspectName and the
localPropertyName are in error then you need to choose which to identify
as the error you are reporting, or yet again report a non-standard
combination error.

I'm satisfied that this is not going to cause interoperability problems
whichever way it is done.

Jo

On 03/06/2008 09:53, JOSE MANUEL CANTERA FONSECA wrote:

> I don't agree. If you consider triples (vocabulary,aspect,localpropertyName) as "properties" then every time a property, aspect or vocabulary is not recognized you will receive a property not recognized exception code, which it is not correct. I prefer to say explicitly that the combination of the three things is not legal, and avoiding other complications or "particular interpretations" of what a property is
>
> Best Regards
>
> ________________________________________
> De: [hidden email] [[hidden email]] En nombre de Jo Rabin [[hidden email]]
> Enviado el: martes, 03 de junio de 2008 10:23
> Para: [hidden email]
> Asunto: Re: [API] What should happen if ...
>
> My understanding is that a fully spelled out property identifier has a
> vocab, an aspect and a localPropertyName. Effectively the vocab and
> aspect namespace the localPropertyName so it is appropriate to throw a
> PROPERTY_NOT_KNOWN in the case where the vocabulary and aspect are known
> but the localPropertyName does not exist within that namespace.
>
> As far as I know, we don't spell out that localPropertyNames of
> different aspects MUST be the same if they refer to the same thing, nor
> that they MUST be different if they don't. We did construct this system
> so that "vendor" when used as a localPropertyName in different aspects,
> COULD have the same meaning.
>
> So to say that a localPropertyName does exist but not for the given
> aspect is taking the logic of our system of vocabularies too far, in my
> view. This is the "Simple API" and one of the aspects of simplicity is
> that we chose not to spell this matter out.
>
> I believe that an extension to our system would introduce the idea of
> "term". A "term" would be a term of the vocabulary, not a name in an
> aspect. In this case it would be right to have an additional exception
> ASPECT_DOES_NOT_HAVE_TERM (or something). But as we have it today, where
> a localPropertyname is indeed local to the Aspect I think that
> PROPERTY_NOT_RECOGNIZED is correct.
>
> Jo
>
>
>
> On 03/06/2008 08:11, JOSE MANUEL CANTERA FONSECA wrote:
>> I agree with you Rotan, maybe we are a bit late to add a new exception code to the spec, however we can do it in our implementation
>>
>> Best Regards
>>
>> -----Mensaje original-----
>> De: Rotan Hanrahan [mailto:[hidden email]]
>> Enviado el: lunes, 02 de junio de 2008 21:53
>> Para: Rafael Casero; [hidden email]
>> CC: JOSE MANUEL CANTERA FONSECA
>> Asunto: RE: [API] What should happen if ...
>>
>> We defined the method getPropertyValue(...) to throw a NameException. The spec also allows it to throw a SystemException but that would not be appropriate in this case. The "name" in this case is a compound, just like having a first name and a family name. If you do not use the right parts of the compound name, then you are not properly identifying something. You are either identifying something else, or you are not identifying anything at all.
>>
>> "Not Known" is a different issue. This is a situation where a property has been correctly identified (by its local name and associated aspect) but there is no data to go with that property. In this case, it is the property value that is not known (emphasis: the property *is* known, it is the *property value* that is not known). You will get a ValueException with code NOT_KNOWN if you try to use a value of a property that is not known, but you can avoid this exception by first testing to see if the value exists in the repository, using the exists() method.
>>
>> In the example, José has not named anything that is understood by the implementation. The particular implementation I assume knows the Core Vocabulary, and nothing in that vocabulary matches "webBrowser & inputDevices". So in this case the problem is in identification (i.e. naming) so the correct exception to throw is a NameException. We assume that in this example the vocabulary *is* known, so the exception code will not be VOCABULARY_NOT_RECOGNISED. That leaves two possible remaining codes:
>>   PROPERTY_NOT_RECOGNISED
>> and
>>   ASPECT_NOT_RECOGNISED
>>
>> This then leads to the real problem, which has been identified in José's original message: which of these two codes is the more appropriate? We do have a third option, because (as mentioned in section 4.4.4) we are not obliged to actually set the code, so in theory we could set no code. The issue is that none of the codes that are associated with a NameException actually identify the particular case where both the property name and aspect are valid, but not their combination. This does not prevent the throwing of the exception, nor does it prevent us from dealing with this general case, which is that a valid Property has not been identified. If an implementation is sensitive to such detail in the exception, then the specification permits further refinement through additional codes.
>>
>> To further complicate matters, consider the VOCABULAR_NOT_RECOGNISED code again. The actual cause of the error might be with the choice of vocabulary. Perhaps in an alternative vocabulary the combination of local property name and aspect name would be valid. The safest interpretation is that none of the three possible codes are strictly appropriate insofar as it is not necessarily clear what is the root cause of the exception. Therefore throw an exception *without* a particular code, but (as the specification clearly says) include appropriate explanation in the accompanying diagnostic message.
>>
>> ---Rotan.
>>
>> ________________________________
>>
>> From: [hidden email] on behalf of Rafael Casero
>> Sent: Mon 02/06/2008 17:33
>> To: [hidden email]
>> Cc: JOSE MANUEL CANTERA FONSECA
>> Subject: Re: [API] What should happen if ...
>>
>>
>> For me makes sense c) because property is not recognized in the subset defined by all the properties that an aspect has, but a) is Ok too.
>>
>> Raf.Casero
>>
>> -------- Mensaje Original --------
>>
>>         If a "not making sense" (aspect, property) combination (being 'aspect' and 'property' two recognized elements of a vocabulary) is used for invoking the API, example
>>
>>         Service.getPropertyValue('http://www.w3.org/2008/01/ddr-core-vocabulary', 'webBrowser', 'inputDevices');
>>
>>         Possibilties:
>>
>>         a) NOT_KNOWN exception thrown
>>         b) Aspect not recognized exception thrown, however the aspect actually is a valid aspect for that vocabulary
>>         c) Property not recognized exception thrown, however the property actually is a valid property for that vocabulary
>>
>>         I'm more inclined to say a), however the point is that the combination of aspect & property is not a valid (legal), according to the DDR Core Vocabulary.
>>
>>         I think that an implementation should throw a NAME_EXCEPTION with an error code saying "Aspect, Property combination not valid"
>>
>>         What do others think?
>>
>>         Best Regards
>>
>>
>