[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] Core versus Extended Profile Handling
> Yes exactly. I had thought of that casually, but dismissed the concern based > on the assertion that if things start getting shared across profiles, they > belong in the core. This eliminates the multiple inheritance anomaly. Which requires the core to be uprev'd, complicating the existing deployments. Once you uprev the core, then existing servers join the crowd of servers unable to say "unknown option" but must instead say "unknown document" which masks the real error. Also, I don't believe that just because 'n' profiles want the same element, that the core must be changed. What's the value of n? Who determines? > Until then, the profiles can unofficially respect the other > published profiles as much and to the extent they can. But they can't. If A wants to use B's profile, then A must define its own element and include the set of (B-core) in A. Now if someone wants to use A and B in C, they have to include (A-B)(B-core) in theirs. And so on. Now imagine A gets a new revision and wants to add a feature of C. How do you do that? My head hurts. :) We want to allow distributed extension without reliance on any central authority. (Kinda the whole point of the web, no?) So having a standard place to "put your processing extensions here" seems to fit that. It fits what X509 does, DSIG does, etc. > My real motives for expressing things for explictly (and less nebulously) > stems from a desire to reduce implementation complexities for our clients. Seems that having a single request, where additional elements get stuffed is a lot simpler than having to know about (several) different namespaces for different requests. But I admit that this is purely an implementation detail, and we're at the "arguing by anecdote" stage. {much deleted) I understand your desire in making it simple to map this into native object-model RPC. I don't share the desire. Our rather, I see that as less important than getting a real extensible protocol specified. And implementations that want to do this can always write a "custom" WSDL that fills in some of the spaces in the Options element. /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]