Re: service-provider extension patch

[Dan Williams <dcbw redhat com>]

On Wed, 2010-06-16 at 17:20 +0100, Neil Williams wrote:
> On Wed, 02 Jun 2010 01:08:57 -0700
> Dan Williams <dcbw redhat com> wrote:
> 
> > On Tue, 2010-05-25 at 10:37 +0100, Neil Williams wrote:
> > > On Mon, 24 May 2010 16:46:34 -0700
> > > Dan Williams <dcbw redhat com> wrote:
> > > > - When two <dtmf> are listed, what's the difference between the two?  Do
> > > > both do the same thing?  Or are they different?
> > > 
> > > The same "networkID" can have differing implementations from which the
> > > user needs to select according to local requirements like tariff or
> > > locality or handset. Our UI offers a default and then allows the user to
> > > choose from the alternatives.
> > 
> > Is it useful to tag those different implementations with a name?  We
> > could add a name to each of the items that need it, though it can't be a
> > property, it'd have to be a sub-element so that it could be localized.
> 
> Each definition is more of a fallback than a discrete alternative. We
> don't have a reliable way of mapping one alternative to one particular
> description. Current theory is that service providers themselves
> "adopt" new details when taking over smaller networks etc. and then fold
> those into the main network such that whichever method works gets
> through to the same network space. So some items will be legacy and
> some will be ongoing alternatives which providers maintain for their
> own reasons (and could drop or switch at any time). We really cannot
> tell from this end. Where both alternatives work in our tests, there
> appears to be no way to distinguish one alternative from another,
> except by changes which would be inherent in the type of interface.
> 
> There may have been a name tag for some alternatives but there is also
> no guarantee that providers will continue using the same name on the
> handset, leading to confusion.
> 
> All we have been able to establish is that certain alternatives do
> appear to be a sane default and those are listed first.
> 
> > > > - For the SMS balance check, when two <sms> items are listed, what's the
> > > > different between the two?
> > > 
> > > Handset / regional / tariff based differentiation. The user configures
> > > which of the available methods to use, the choice is then stored in
> > > the application.
> > 
> > Again, might make sense to have <name> and <desc> subelements to give
> > users some help here too.
> 
> If we could know that the name or desc would be persistent then that
> would be useful. That just doesn't appear to be a reliable assumption
> and is outside user control, sadly.
>  
> > That would mean changing the format a bit though to something more like:
> > 
> > <voicemail dtmf="901">
> >     <name xml:lang="de">asdfadfadf</name>
> >     <desc xml:lang="de">Blah Blah</desc>
> > </voicemail>
> > 
> > and the same for the rest of the items.  Or replace the "dtmf" attribute
> > with an element inside voicemail perhaps.  Either way.  Maybe we don't
> > actually need name/description for some of these?  The issue is that if
> > we go with the format you're suggesting, it's really hard to add
> > localized name or description later without breaking the DTD.
> 
> From this end, it looks more like adding names or descriptions (and
> then translating them) is more likely to be misleading and error-prone,
> causing more work for everyone.
> 
> > I'd also like to see comments in the DTD if we can stuff them in about
> > what each of the new fields is, like you've described them here.  That
> > makes the DTD more of a "specification".  Or if that's not the right way
> > to do it, at least comment about them at the top of the XML file.
> 
> Comments added to the DTD.
>  
> > > No problem. Further updates may follow as more devices get out to real
> > > users. Network methods can be impossible to test without real access to
> > > the network itself.
> > 
> > Completely understood.  Think you'd be able to respin the patch with the
> > suggested changes?
> 
> I'm attaching a revised patch with the DTD comments to replace the
> first one we sent.

Pushed, thanks!

Dan