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




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