Talk:ALF/architecture/ALF Schemas 001

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

Additional Changes - 2. Eliminate the "required" attributes.

"schemaLocation" attributes. The purpose is to allow dynamic discovery of the concrete schema when you receive an event as a Base event. My thought is that this use is unlikely and if it was to be used it may be better defined at a higher level. The tool event declaration schema (see elsewhere on declaring events) can define the entire event structure for the tool's events and would be interesting at the Event level. Thus instead of two attributes for Detail and Extension we might have just one at the ALFEvent level thus

	<xs:complexType name="ALFEventType">
		<xs:sequence>
			<xs:element name="Base" type="EventBaseType"/>
			<xs:element name="Detail" type="EventDetailType"/>
			<xs:element name="Extension" type="EventExtensionType"/>
		</xs:sequence>
		<xs:attribute name="schemaLocation" type="xs:string" use="required"/>
	</xs:complexType>

I'm a little bothered by this being "required". I suppose the default could be the ALFEventSchema location for those tools that do not extend the event in any way. Even those should declare their events so maybe there is always a possible specific schema.

Tim

on Additional Changes - Eliminate the "required" attributes.

alfEventVersion on EventBaseType (nee BasicEventType)

posted for Brian Carroll

We need to keep the alfEventVersion or find an alternative mechanism to allow applications to process events as the definition of the event evolves over time. Since we cannot mandate that all tools switch over from one version to another on a specified date, we need a mechanism to allow not only the EventManager, but also tools to accept and process different versions of the event message even as its format evolves. Having an event carry explicit indication of what format was used allows ALF to evolve without trauma to the EventManager or applications.