OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[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")


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]