[standards-jig] Re: PubSub question

Jean-Louis Seguineau/EXC/ENG jean-louis.seguineau at antepo.com
Tue Jul 15 18:43:55 UTC 2003


Yes I understand that it has a different semantic.

This was not the point I was trying to make, sorry, and I am not saying you
must use <option>. I was just feeling that using two tags in this could be
reduced to using only one to convey the same meaning because that construct
is not used anywhere else.

And finally because I was feeling that <subscribe-options> looked somewhat
odd in the middle of single word tags, but that just a matter of aesthetics
:)

--jean-louis

----- Original Message ----- 
> Message: 2
> From: "Peter Millard" <me at pgmillard.com>
> To: <standards-jig at jabber.org>
> Subject: Re: [standards-jig] PubSub question
> Date: Mon, 14 Jul 2003 12:47:38 -0600
> Reply-To: standards-jig at jabber.org
>
> Jean-Louis Seguineau/EXC/ENG wrote:
> > Hi all,
> >
> > Re-reading JEP0060 if was just wondering if there was a particular
reason
> > for having  a somewhat convoluted <subscribe-options> tag that is only
used
> > to specify that configuration is required for a subscription (see
example
> > 40)
> > Wouldn't it be simpler to have just a single tag instead as described
bellow
> [Examples snipped]
>
> This was done because the two elements have different semantic meaning.
They
> also have different schemas. Note that the <subscribe-options> tag
indicates
> that your options MAY (or MUST depending on the presence of the
<required/>
> child element) be configured. This is basically a notification from the
system
> to the user.
>
> The <options> element is used to actually request and set my current
options.
> This is very differenet from a notification. This combined with the fact
that
> the two elements have different schemas is why I used two different
element
> names. Note that <subscribe-options> is only valid as a child of entity,
while
> <options> is only valid as a child of the pubsub element itself.
>
> pgm.




More information about the Standards mailing list