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: public-ddwg-request@w3.org [public-ddwg-request@w3.org] En nombre de Jo Rabin [jrabin@mtld.mobi]
> Enviado el: martes, 03 de junio de 2008 10:23
> Para: public-ddwg@w3.org
> 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: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 09:14:33 UTC