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


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


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