[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] SchemaType#ref.
We can discuss it, but we probably should not spend a long time on it.
If nobody else cares, then I'm okay with saying that a *reference* to a
schema is good enough. Jeff is probably right when he says that most
requestors and providers will simply "recognize" schemas that they
already "know". After all, we already assume a certain level of
pre-arrangement (e.g., for trust relationships).
As far as I can see, requiring each target to include the schema would
be important only for "generic" clients that expected to parse the
schema content itself. Based on current usage, that seems a little like
science fiction. Jeff's assumption of pre-arrangement (or that
requestors hard-code support for specific schemas) may be more realistic.
Darran Rolls wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> 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]