Difference between revisions of "Talk:ALF/architecture/ALF Schemas 001"

Revision as of 15:09, 14 September 2006

Please comment on this document here

on Additional Changes 1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.

- posted for Brian Carroll The intent of separating the two parts of the payload into the standard part defined by an ALF Vocabulary and tool-specific extension data was to allow for tool substitutability. Any arbitrary tool that understood the ALF Vocabulary-defined portions but not the tool-specific data could still process the standard portion of the payload. Separating the standard ALF Vocabulary-defined portions from the tool extension data make the event more generically process able by tools that simply understand the ALF Vocabulary portion. We need to keep that separation.

- reply from Tim Buss Yes it does force the division. My concern is that it creates an artificial division from a data usage perspective and perhaps the need that it tries to address could be addressed differently. An alternative might be to say that vocabulary structures must be extensible eg:

Defining ALFEventType as

	<xs:complexType name="ALFEventType">
		<xs:sequence>
			<xs:element name="Base" type="EventBaseType"/>
			<xs:any minOccurs=0>
		</xs:sequence>
		<xs:attribute name="version" type="xs:string" use="required"/>
	</xs:complexType>

Allows the omission of the two extra elements that we currently require but may often be empty.

Vocabulary details can be declared as follows. Note that xs:any allows them to be extended to include additional elements. This allows for compatible type extensions and xs:any can be added at all structure levels allowing a tool to declare its extra data with close proximity to the vocabulary elements to which it is probably related.

For example:

	<xs:complexType name="VocabStructure1Type">
		<xs:sequence>
			<xs:element name="VocabElement1" type="xs:string"/>
			<xs:element name="VocabElement2" type="xs:string"/>
			<xs:element name="VocabStructure2" type="vocabStructure2Type>
			<xs:any minOccurs=0>
		</xs:sequence>
	</xs:complexType>

	<xs:complexType name="VocabStructure2Type">
		<xs:sequence>
			<xs:element name="VocabElement3" type="xs:string"/>
			<xs:element name="VocabElement4" type="xs:string"/>
			<xs:any minOccurs=0>
		</xs:sequence>
	</xs:complexType>

Giving the vocab event definition.

	<xs:complexType name="MyVocabEvent1Type">
		<xs:complexContent>
			<xs:restriction base="ALFEventType">
				<xs:sequence>
					<xs:element name="Base" type="MyEventBase3Type"/>
					<xs:element name="Detail" type="VocabStructure1Type"/>
					<xs:any minOccurs=0>
				</xs:sequence>
				<xs:attribute name="version" type="xs:string" use="required"/>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>

Given this vocab definition, a tool is free to added elements either inside VocabStructure1Type or to ALFEventType but the event can still be handled using just the generic vocabulary if so desired.

Another possible advantage of this method is that we can control what is a vocabulary schema and define that it be extensible in this way. This may be easier enforce than whether a particular tool declares its detail/extension elements within one arbitrary element or another.

Another possible advantage of this method is the these extensible vocabulary structures can also be applied to service defintions. The brute force division by element we have so far proposed is not very convenient for that or likely to be observed. To be sure that this alternative method would work for services we would need to try it with the various service proxy generators to reasure ourselves that <xs:any minOccurs=0> is currently handled appropriately and is practical to use. It will work fine for the eventManager and BPEL.

Probably need to play with this idea a bit more to be sure but I think it may be a compelling alternative.

Tim