+1 on the goal of allowing extensibility without requiring revisions to core, by allowing
additional non-predefined elements to be carried (much like SOAP headers, yes?)
regards, Frederick
Frederick Hirsch
Nokia Mobile Phones
> -----Original Message-----
> From: ext Rich Salz [mailto:]
> Sent: Thursday, November 06, 2003 3:15 PM
> To: Edward Shallow
> Cc:
> 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
>
>
> To unsubscribe from this mailing list (and be removed from
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave
> _workgroup.php.
>
>
