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:rotan.hanrahan@mobileaware.com]
> Enviado el: lunes, 02 de junio de 2008 21:53
> Para: Rafael Casero; public-ddwg@w3.org
> 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: public-ddwg-request@w3.org on behalf of Rafael Casero
> Sent: Mon 02/06/2008 17:33
> To: public-ddwg@w3.org
> 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
> 
>

Received on Tuesday, 3 June 2008 08:24:40 UTC