[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] SchemaType#ref. (was "Draft 15 of the SPML XSDs")
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]