[
Lists Home |
Date Index |
Thread Index
]
> From: Jeff Lowery [mailto:jlowery@scenicsoft.com]
<snip/>
> Perhaps more to the point is:
>
> Should one mix XML-formatted process descriptions with metadata?
>
> In other words, have one schema for process description and
> another for data
> description. Do these two descriptions have to be tightly
> bound in the same
> document?
When that can be easily achieved, I think that makes sense. However, this
can get messy.
We tend to employ hierarchical messages that indicate an action with
associated data, but which also includes embedded child actions that are
evaluated in the context of the containing action and its associated data.
For example, we may have a message with a root element "updateContact" that
contains elements for name, title, etc. But it may also contain an
"updateAddressInfo" element, which itself contains "updateAddress",
insertAddres", or "removeAddress" elements, each containing data relevant to
an address record associated with the contact that should be added, removed,
or updated. (Note that the use of the term "record", here, should not be
interpreted as meaning the XML, in our case, is just a straightforward
mapping of a database record. We are operating at a layer of abstraction,
here, above the actual database structures used.)
The structure of the data within each command can also change slightly
dependent upon the command. For example, an "update" or "remove" message
must include some key that can be used to match up with the corresponding
data (either our system's object id, or a unique marker used by an external
system for synchronization of data), whereas an "insert" may omit such a key
(and if a key is included, it must be the unique marker used by the external
system for synchronization, not the object id assigned by our system).
I think this could often be modelled, though, by specifying the data as an
XML Schema type, and having the command be an element that extends that
type.
|
