[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] SchemaType#ref.
Shall we add this to the agenda for tomorrows call? If so, attendees please come armed with an opinion :-) Darran Gary P Cole wrote: > Does anyone (other than myself and Jeff) have an opinion? Should the > provider's response to listTargets always *include* the schema (as > content of the <schema> element)? Or is it enough simply to *refer* to > the schema (by identifiying its namespace or by giving the location of > an XSD file)? > > Bohren, Jeffrey wrote: > >> No. >> >> Jeff Bohren >> >> -----Original Message----- From: Gary P Cole >> [mailto:Gary.P.Cole@Sun.COM] Sent: Wed 3/23/2005 3:42 PM To: >> provision@lists.oasis-open.org Cc: Subject: Re: [provision] >> SchemaType#ref. (was "Draft 15 of the SPML XSDs") >> >> >> >> If a <schema> element does NOT have a "ref" attribute, then MAY a >> provider omit the content of the <schema> element? >> Bohren, Jeffrey wrote: >> >> >>> Regardless of whether the ref attribute is a location of just a URN, >>> the <spml:schema> may omit the profile specific schema information. >>> The client and service would either retrieve the schema information >>> from the location or use schema information known a priori. >>> For the XSD Profile, I think it is unlikely that an SPML client is >>> going to >>> >> >> >> >> >>> do anything useful with XSDs retrieved from a location defined in >>> the ref attribute. Most likely it is going to use the ref to match >>> to a known XSD schema regardless if it is a URN or an actual XSD >>> location. >>> Jeff Bohren >>> -----Original Message----- From: Gary P Cole >>> [mailto:Gary.P.Cole@Sun.COM <mailto:Gary.P.Cole@Sun.COM> >>> >> >> ] >> >>> Sent: Wednesday, March 23, 2005 3:13 PM To: >>> provision@lists.oasis-open.org Subject: Re: [provision] >>> SchemaType#ref. (was "Draft 15 of the SPML XSDs") >>> So.... >>> If a <schema> element has a "ref" attribute and if the value of the >>> "ref" attribute is a *location*, then MAY a provider omit the >>> content of the <schema> element (perhaps based on the assumption >>> that the requestor can access the XSD file resource that location >>> specifies)? >>> If a <schema> element has a "ref" attribute and if the value of the >>> "ref" attribute is an *identifier*, then MAY a provider omit the >>> content of the <schema> element (on the assumption that the >>> requestor will/should/must recognize the identifier and know the >>> schema a priori)? >>> Or SHOULD a provider *always* include the schema (as content of the >>> <schema> element)? >>> Bohren, Jeffrey wrote: >>> >>> >>> >>> >>>> I would prefer to leave it as single attribute. The reference can be a >>>> >>> >> real >> >>>> location or URN that both parties know a priori. >>>> Jeff Bohren >>>> -----Original Message----- From: Gary P Cole >>>> [mailto:Gary.P.Cole@Sun.COM <mailto:Gary.P.Cole@Sun.COM> >>>> >>> >> ] >> >>>> Sent: Wednesday, March 23, 2005 1:39 PM To: >>>> provision@lists.oasis-open.org Subject: [provision] SchemaType#ref. >>>> (was "Draft 15 of the SPML XSDs") >>>> XSD 15 addresses every issue in the list except 51, which concerns >>>> SchemaType#ref. >>>> (For the sake of brevity, I'll cut to the chase. Background from >>>> the email thread on this issue and some analysis are included below >>>> after my signature.) >>>> I propose that we replace "ref" with two separate attributes: >>>> "namespaceURI" and "location". An identifier such as "namespaceURI" >>>> could help the requestor to recognize included schema content. A >>>> location could actually replace included schema content. >>>> Perhaps we should go even further and make these exclusive >>>> options. SchemaType could offer a CHOICE between "namespaceURI" >>>> and "location". >>>> Gary >>>> <BACKGROUND> SchemaType extends ExtensibleType, so it may contain >>>> anything. TargetType contains an element of SchemaType named >>>> "schema" that ordinarily contains the actual schema data. >>>> SchemaType#ref is defined as optional attribute of type "anyURI". >>>> As a URI, #ref could be just an *identifier* or #ref could be a >>>> >>> >> *location*. >> >>>> On 12/14 I asked two questions: >>>> 1) When the value of the SchemaType#ref attribute is the *location* >>>> of a schema document, is this an *alternative* to including the >>>> schema document as content of the <schema> element? >>>> 2) Would it be clearer to have separate attributes (as we do for >>>> CapabilityType): - one that identifies the schema ('namespaceURI') >>>> and - another that gives the location of a schema document >>>> ('location')? >>>> Jeff Bohren replied: >>>> If the schema is defined by inclusion instead of reference, the >>>> schema would be included in the target returned by the list target >>>> response. For instance for XSD documented schemas: >>>> <spml:target> <spml:schema> >>>> <xsd:schema>...</xsd:schema> </spml:schema> ... </spml:target> >>>> </BACKGROUND> >>>> <ANALYSIS> I *think* this answers "yes" to question #1, although it >>>> is not completely clear to me. >>>> 1) Is reference is intended to be strictly alternative to >>>> inclusion? - A reference *location* could replace included schema >>>> content, but a reference *identifier* may not. - A reference >>>> *identifier* may help the requestor to recognize an included >>>> schema, so an identifier would be useful even with inclusion. - A >>>> reference (identifier or location) could conflict with included >>>> schema content. If so, how should a requestor handle this? - >>>> Should inclusion and reference be true alternatives (exclusive >>>> choices)? (For example, should TargetType perhaps offer a CHOICE >>>> between a SchemaType element and a "ref"?) >>>> For CapabilityType we use two separate attributes (both of type >>>> anyURI) to distinguish "namespaceURI" (required) from "location" >>>> (optional). It seems to me that it would be appropriate (and much >>>> clearer) to do the same thing for SchemaType. </ANALYSIS> >>>> Jeff Bohren wrote: >>>> >>>> >>>> >>>> >>>> >>>>> Attached is draft 15 of the SPML XSDs. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: provision-unsubscribe@lists.oasis-open.org >>>> For additional commands, e-mail: provision-help@lists.oasis-open.org >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: provision-unsubscribe@lists.oasis-open.org >>>> For additional commands, e-mail: provision-help@lists.oasis-open.org >>>> >>>> >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: provision-unsubscribe@lists.oasis-open.org >>> For additional commands, e-mail: provision-help@lists.oasis-open.org >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: provision-unsubscribe@lists.oasis-open.org >>> For additional commands, e-mail: provision-help@lists.oasis-open.org >>> >>> >>> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: provision-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: provision-help@lists.oasis-open.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: provision-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: provision-help@lists.oasis-open.org >> >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: provision-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: provision-help@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]