Subject: Re: output port groups WAS(Re: Revised LFB input/output text

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 5 May 2004 09:41:15 -0700

See below between [Yang, Lily L] and [/Yang, Lily L]

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Wednesday, May 05, 2004 9:09 AM
To: [email-masked]
Subject: output port groups WAS(Re: Revised LFB input/output text

Let me jump to this email because it puts us back on track - then i will
revisit the other emails including this because they still have
interesting discussion points.

On Wed, 2004-05-05 at 11:22, Alistair Munro wrote:

> We might also be losing sight of the original issue (IMO), which was
> groups. No, I don't really understand them either, but I can live with
> them. The rules for using them seem clear enough to allow
interoperability.

I can live with them as well. I see logically not more than two groups
if you insist on grouping. Otherwise we need to explain why we need
more. There was something about XML connotations needing it.
Again, to reitarate my position i dont see why you need groups.

[Yang, Lily L] Let me try one more time: 
1) We don't live or die for "group". In another word, with or without,
we can still make it work.
2) But, IMHO, the concept of "group" allows better delineation of the
semantics in input/output. Take the example of one LFB with one
"exception-output" and n "normal-output". Yes, you can represent that as
output 0, 1, ... n (that is, just one group). But with this construct,
you lose the semantic difference of output 0 from 1 to n. With the
concept of grouping 1 to n together, you retain that semantic meaning in
the construct itself.
3) What do we lose without "group"? I've shown that in 2). Now what do
we lose with "group"? Does "group" impose more complexity for LFB
designers? Absolutely not. Yes, it means one more concept to wrestle
with in the model document, but if it is useful, then it is worthwhile.
Besides, we are wrestling with it already :-)
4) No, the point about XML is misunderstood here. I think we all agree
that we need to allow multiple outputs for some LFB so that they can
fork. One argument is to allow it only for special LFBs like redirector.
If we take that approach, it means the XML schema would not be the same
for every LFB. That doesn't seem like a good design, and so the model
team is more in favor of the generic schema that allows multiple output
(including groups) for any LFB, as long as it makes sens.
[/Yang, Lily L]

The other contention point is the naming around "redirector".
[Yang, Lily L] Don't seem too contentious to me. I don't mind if you
have better name. I can live with demux if that makes you happier.
[/Yang, Lily L] 

Both the above seem to me to be overzelous future-proofing design. Ok,
there i said it.

[Yang, Lily L] Depends on the price you pay for that future-proofing. If
it is cheap, why not? I think that is the case here.
[/Yang, Lily L]

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 May 2004 14:48:34 -0400

Hi Lily,

On Wed, 2004-05-05 at 12:41, Yang, Lily L wrote:

> semantics in input/output.

As i said earlier, the input text is allowing me to ignor or lave with
grouping so i am fine with it. The only challeneg is in the output.

> Take the example of one LFB with one

I am not sure i agree theres any semantic loss, but i can live
with that because it doesnt make a difference for me.
So, ok -  two groups.

> Besides, we are wrestling with it already :-)

for one it is confusing. Ive asked for a sample of a legit example with
more than one group + exception and noone is responding on that point;->

> (including groups) for any LFB, as long as it makes sens.

I think too much genericity may be dangerous. Because LFB class Y and
class X need it doesnt equate class Z need it.
Refer to my email to Alan; this is probably solvable by defining the
granularity levels.

> have better name. I can live with demux if that makes you happier.

Anything but redirector.

> it is cheap, why not? I think that is the case here.

Confusion is not cheap friend ;->

cheers,
jamal