Re: [provision] SchemaType#ref.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

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