OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] XML Schema and conformance requirements


I like the approach of bringing together "common extensions".

Would the set of extension elements be defined under a single schema
definition, multiple schemas or just individual elements?  My initial though
is multiple schema may be best, where each extension schema defines a set of
elements that logically work together to support a given function (e.g.
encapsulated signature containing transformed data).

Nick

> -----Original Message-----
> From: Rich Salz [mailto:rsalz@datapower.com]
> Sent: 17 September 2003 18:46
> To: Nick Pope
> Cc: Juan Carlos Cruellas; dss@lists.oasis-open.org
> Subject: Re: [dss] XML Schema and conformance requirements
>
>
> > a) several of the application profiles will use the same set of
> elements.
>
> I would like to understand why this is a problem.
>
> > b) We will get a multitude of documents.
>
> See below.
>
> > c) There several different places in which we would want to add
> extensions
>
> I don't believe this is true.
>
> > Is there a way that we can collect together some generally
> useful elements
> > that we do not expect all implimentations to support but are
> applicable to
> > several applications profiles into one or very few documents.
>
> Yes.  We could issue a "common extensions" document that defined a
> handful of dss:Parameter elements for various things.  The spec could
> say if you support this element, then it must be with the semantics
> defined here.  You could then make an easy interop matrix that listed
> the URI's of all the elements, and vendors and customers (and interop
> testing) could make a check-list of the URI's that are supported.
>
> > I am not sure what you mean by "standards profile" as apposed
> to application
> > profile and how this relates to use of extensions
>
> I mean things like the way WS-I says "only use doc/literal not
> rpc/encoded for SOAP."  Or the way IETF PKIX says how to use X.509.
> It's where one document defines a "subset" (not strictly in the PKIX
> case, perhaps) of another.  That's a standards profile.
>
> An application profile would be a URI embedded in each request that
> indicates to the DSS server what behavior(s) the client wants.  For
> example, "urn:tpu.int:timestamp:1.0" could be the URI that clients send
> if they want a postal-service timestamp.
>
> Is that a better explanation?
>
> 	/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_wor
kgroup.php.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]