[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Top down or bottom up
I've tried to summarize what I think the issues are: 1) Are we defining a framework for assertions? 2) Where do we reduce freedom in order to standardize 3) Should we define cardinalities of relationships (this must have 1 of these and 2 of those) as part of #2? I also include comments. > -----Original Message----- > From: Phillip Hallam-Baker [mailto:pbaker@verisign.com] > Sent: Tuesday, May 15, 2001 10:44 AM > To: Orchard, David; security-services@lists.oasis-open.org > Subject: RE: Top down or bottom up > > > > Well, I'll bite at the bait. Unfortunately, due to > > circumstances beyond my > > control, I don't have as much time to write a response as I'd like. > > > > Which use cases do you believe bottomish makes easier than > > toppish? > > I believe that both mechanisms can meet the use cases specified. > > However the use cases specified may be unrealistic in being more > abstract and simplified than practical implementations would require. > > The bottomish approach would provide more flexibility should > practical experience prove that the original use case analysis > was wrong. > I'd like to see the use cases and requirements why toppish shouldn't be done. I don't think I'm amenable to doing something the opposite of what I propose without some justification. > > One of the ideas that these discussions and proposals seems > > to have brought > > is a scope discussions about whether we are defining a framework for > > assertions or assertions themselves? > > If we adopt a layered design methodology we do both. > Does the rest of the TC believe that we are defining or should be defining a framework for assertions? I'm interested in the will of the group on this very important design goal that seems to have been overlooked yet slipped in. This seems issue #1 in this discussion. > > > I think one of your objections to > > toppish typing is that it locks implementations into a > > particular model. But isn't that what we want? > > My end goal is to satisfy as many customers as possible, thus > causing all our stock options to increase in value. > > I have no interest in attempting to lock anyone into anything. > My end goal is to satisfy as many customers as possible, and I assert that in some areas people must be locked in to something. Every successful standard has locked in something. The question is where should we do it in SAML. And I assert that defining cardinalities of assertions is one of those things. The question about where to allow flexibility seems to be issue #2. > At a recent workshop Dave Clarke ripped into certain wireless > technology on the basis that the entire range of uses had been > designed in, the technology was designed to insist that it only > be used as intended. That doesn't really help in the analysis. > > >I assert that successful standardization > > requires reduced flexibility and locking into a particular > > model. SOAP is a > > good example of locking users into a particular model for > > headers, body, > > requests, responses, parameters, etc. Java is another example. > > That is quite different. The design does not reduce functionality, > it reduces the number of means of achieving a given functionality, > a very different issue. I think that I'm catching the drift, that you argue keeping assertions as effectively mixed content where anything can be thrown in is a good thing. > > > The arguments that you are making, particularly to Pascal and > > to reduced flexibility, leads me to believe that you are of the > > weakly-typed camp, ala > > Smalltalk. Whereas I've been a strongly-typed proponent, ala > > Java and C++ > > Would strong versus weak types be an accurate analysys of the > > toppish versus > > bottomish typing? > > It would be a complete misrepresentation of my position. > > C++ is in my view a weakly typed language. I have worked extensively > with true strongly typed languages such as Z and VDM. > > The core fallacy of the Pascal 'type' system is that Wirth failled > to understand the distinction between type and representation. > I've never had the luxury of working with languages outside the mainstream of developers, so I typically base my examples on C, C++, Java. I think I might share Wirth's failing. OTOH, I've never created a language that we can all talk about. I don't understand why you view C++ as a weakly typed language, but that's probably another thread. I had hoped to gain some insight, but I'm now more confused. > > One way I'd summarize the toppish versus bottomish as specify > > cardinalities > > or not. > > Confusion of type systems and syntax has long been considered an > error in language design. > You didn't say whether specifying cardinalities was an adequate summary of the difference in the proposal. I'm still curious as to the answer. I think this is issue #3 out of this. Again, you are asking me to endorse something simply because you assert that it is an error in design, or in this case you assert that unnamed others assert it. I'm just a simple guy that understands a few programming languages and a bit of this thing known as XML Schema. XML Schema and my understanding of good standards design leads me to want to specify cardinalities of things rather than unbounded content models. Cheers, Dave
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC