[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]