Xml Messaging
Rick Sanderson
ricks at fourbit.com
Wed Sep 22 18:21:30 BST 1999
I Wrote:
> >should XML messaging be based
> >on a "metadata" language, or on a "domain" language?
> >Method 2: "Domain" language
> >-------------------------------------------------------------------
> ><message>
> > <update target="accounting" id="1">
> > <GlAccount oid="12345" version="1">
> > <ChartOfAccounts oid="47"/>
> > <GlAccount.name>Bank Account</GlAccount.name>
> > <GlAccount.type>Asset</GlAccount.type>
> > <Balance>
> > <Currency>USD</Currency>
> > <Amount>15000.00</Amount>
> > </Balance>
> > </GlAccount>
> > </update>
> ></message>
Mark Baker wrote:
> That's sort of both, in that "update" is a metastatement about what
is
> intended of the document (which appears to be comprised of the
content
> starting at the GlAccount tag).
>
> Your previous method 1 example requires a translation process that
appears
> unnecessary. Just dump the document (the account) over the wire
with
> sufficient context for it to have the desired effect on the other
end.
We started out using a Domain language. But there are problems (with
both Domain and Metadata) at varying levels of concern:
1. Validation:
I'm no expert, but I'd think that the DTD <!ELEMENT> of 'update' would
need to be #PCDATA or ANY. This is not validation. By extension, I
know of no way to provide a DTD schema allowing for validation of the
actual content (the GLAccount in the example). Is there a mechanism
I've missed?
2. Name collision:
If a DTD were applied in some way, element identifiers would have to
be fully qualified names. In the example, 'GLAccount.name' was used
because an element called 'name' might conflict with another type of
object which structures a name differently than simple text (i.e. a
persons 'name'). This can get messy during implementation when
polymorphism is involved.
3. Partial data:
If a client receives the state of a large object, but changes only a
small part of it, does the client need to transmit back the entire
object, or just changes? The "Metadata" approach [example reproduced
below] seems to better support transmitting changed data only,
especially if one wishes to validate messages. Aside from validation,
this is not really an implementation issue since there is little
difference, but intuitively, "Metadata" seems a better vehicle (for
some unknown reason).
4. Implementation1:
Using a "Metadata" approach is obviously more abstract, and therefore
affords more generic implementations and greater opportunities for
re-use. It is also more flexible and adaptable in the face of change.
5. Implementation2:
Multiple references to one object within a message is easier to create
and handle using Metadata.
6. Content:
Using Metadata is messy if human readers/writers are involved. Our
intent is to allow a server to accept messages regardless of source.
Domain language wins here only if a standard domain language in *our*
domain arises.
7. Efficiency:
Metadata is much more verbose than Domain language, but assuming those
points above hold, this may more than be made up for by flexibility
and the ability to validate.
These are off the top of my head, but I know there are other issues
not coming to me right now.
Despite these concerns pointing toward use of a Metadata language, my
*intuition* tells me that, in the long run, a Domain language will
stand up longer, and better allow for interaction with other systems.
The problem is I have little evidence.
Rick Sanderson
ricks at fourbit.com
Here is the Metadata example of the above XML:
<message>
<command target="accounting" id="1">
<process>update</process>
<object class="GlAccount" oid="12345" version="1">
<context>
<owner class="ChartOfAccounts" oid="47"/>
</context>
<property name="name">Bank Account</property>
<property name="type">Asset</property>
<object name="balance" class="Money">
<property name="currency">USD</property>
<property name="amount" type="float">15000.00</property>
</object>
</object>
</command>
</message>
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev
mailing list