Re: [apps-discuss] Appsdir review of draft-ietf-geopriv-relative-location

[[e-mail] (Henry S. Thompson)]

Martin Thomson writes:

> HST wrote:
>>    Ah, repeated re-readings have uncovered the origin of the problem,
>>    further back:
>> 
>>      "A client that does understand this extension will interpret the
>>       location within the relative element as a refinement of the
>>       baseline location, which gives the reference location for the
>>       relative offset."
>> 
>>    I read that the first five times as if it were bracketed like this:
>> 
>>       [a refinement of [the baseline location, which gives the
>>        reference location for the relative offset]].
>> 
>>    But you mean it as if it were bracketed like this:
>> 
>>     [a refinement of the baseline location], [which gives the
>>        reference location for the relative offset].
>> 
>>    So, I suggest you rephrase the whole sentence along the following
>>    lines:
>> 
>>      "A client that does understand this extension will interpret the
>>       location within the relative element as a refinement of the
>>       baseline location.  The resulting refined location then gives
>>       the reference location for the relative offset."
>> 
>>   With that change, the paragraph containing the first quote above
>>   (the para beginning "The baseline location SHOULD be general
>>   enough") is comprehensible, but still very dense.  I know
>>   illustrations are hard when one is restricted to ASCII-art, but a
>>   pair of examples would be a great help here, where one obeys the
>>   rules, and is not understood wrongly by a non-extension-supporting
>>   app, but the other breaks the rules, and therefore liable to be
>>   interpreted wrongly by such an app.
>> 
>>   And, finally, perhaps just _after_ the example now at the end of
>>   this section, just a brief gloss along the lines of
>> 
>>     The baseline location, given by the first ca:civicAddress element,
>>     the first child of the gp:location-info, is a street address, to
>>     the level of detail of the house number (123).  The reference
>>     location is [now the front door, something else if you fix the 5.1
>>     issue below].  The actual location, which is still within the
>>     baseline building, is a point 100m east and 50m north [?] of the
>>     front door.
>
> Oh.  That's a bigger issue than you make out.  Baseline != reference.

Indeed.  As I tried to explain above, I _finally_ figured that out,
but the text doesn't make it easy.  That's why I suggested a diagram.

>>   4.11.1
>> 
>>     "An 'http:' or 'https:' URL MUST be used unless . . ."
>> 
>>   Wouldn't it be more in the spirit of 2119 to say "A URI with scheme
>>   other than 'http:' or 'https:' SHOULD NOT be used unless" ?
>
> "SHOULD" is a weasel-word that SHOULD be avoided.  I like to reserve SHOULD for cases where I am not providing a clear description of the exception cases.  Most times, MUST works perfectly well if properly qualified.  As I believe this is.

Your call.

>>   6. Schema Definition
>> 
>>   The repeated pattern used for complex type definition in this schema
>>   doc is[[MT]]  ...
>>   This is overly . . . complex and invites confusion, [[MT]] ...
>>   Please simplify all your complex type definitions along these lines.
>
> I'm going to hold the line on this point.  XML Schema defines two
> ways to do the same thing and this draft consistently uses the form
> that permits other uses than complex type restrictions of the
> ur-type.  I see no good reason to switch to the syntactic sugar
> variant.

Your gun, your foot, your bullet.  You will just cause people to
scratch their heads and waste time trying to understand why you used
10 words where one would do.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: [phone], e-mail: [e-mail]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]