Xml Messaging

[Mark Baker]

At 12:20 PM 9/22/99 -0400, Rick Sanderson wrote:
>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?

You're right, strict validation isn't possible of compound documents with
DTDs since they don't allow you to be openly permissive about which
elements can contain which.  XML Schema will presumably help here, but
given the large DTD legacy, it might not matter.  Anyhow, validation by
parts could still be done; it's not validation by any purist's definition,
but it might suffice for your needs.

The way I have set this up (not specifically for validation) is that I bind
a protocol stack on the fly as the SAX events of the received XML message
come in; the first (root) event binds to the first (root - top of the
containment hierarchy) component, and then that component is handed the
rest of the SAX events.  I haven't personally worried about validation, but
at any time one of these components (the GLAccount in your example,
assuming it was validation of that content that mattered) you could
redirect events to a validating SAX parser.

Validating your metadata (like the update container in your example)
probably isn't as important as validating the stateful portion of the
message; the domain document.

>
>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.

XML Namespaces don't suffice?

>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?

Changes.  We're talking messaging here, not RPC.  A single "session" on the
client might result in multiple messages being sent.

>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).

Don't know.

>
>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.

I don't think so.  Evolution of your document schema can occur
independantly of the what you use on the wire.  So you might as well use
your document schema on the wire, IMHO.  Could be wrong on that one though.

>5. Implementation2:
>
>Multiple references to one object within a message is easier to create
>and handle using Metadata.

I don't see that.

>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.

Ditto.

MB

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)