Allowable content in the types element

On last week's call, I took an AI to investigate whether the types 
element allows definition of any type system's components, or whether 
they must be based upon an Infoset data model.

The relevant text is part one, section 3:
>  At the abstract level, the {element declarations} property of  2.1.1 
> The Definitions Component is a collection of imported  and embedded 
> schema components. By design, WSDL supports any schema language for 
> which the syntax and semantics of import  (i.e., the ability to import 
> some schema by reference) or embed  (i.e., the ability to embed a 
> schema directly into another document) have  been defined. However, 
> only the XML Schema implementation is defined in this specification. 
> Instances of WSDL (i.e., WSDL documents) MAY require support for an 
> alternative schema language by using the standard  wsdl:required  
> attribute information item (any imported or embedded XML Schema 
> element information items may be regarded as having this attribute 
> information item set).
[...]
>  The schema components contained in the {element declarations}  
> properties of 2.1.1 The Definitions Component provide the type  system 
> used for Message Reference and Interface Fault components.  Message 
> Reference components indicate their structure and content by using  
> the standard attribute information items element , or for alternate 
> schema  languages in which these concepts do not map well, by using 
> alternative attribute information item extensions. Interface Fault 
> components behave  similarly. Such extensions should define how they 
> reference type system components. Such type system components MAY 
> appear in additional collection properties on 2.1.1 The Definitions 
> Component.

I read this as clearly saying that the abstract constructs contained by 
the types elements must correspond to Schema components. At least one 
other WG member shares this view [1].

There are two basic directions that we could take:

a) Restrict the type components defined in <types> to those based upon 
the Infoset as a data model

b) Allow type components based upon any data model in <types>.

The status quo seems to be (a). To clarify this, I propose we add text 
that limits the data model of type components in the types element to 
the Infoset, and rename the types element to "elements" --  a much more 
accurate name for the contents therein.

(b) is also acceptable, but would require the text quoted above to be 
substantially rewritten.

Given the direction we have taken regarding non-XML data models (i.e., 
requiring different properties to be defined), I find (a) preferable, 
because it makes this separation more clear.


1. http://www.w3.org/mid/40D0A611.2010904@sun.com

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Monday, 5 July 2004 16:26:57 UTC