Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Xml Messaging
 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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
