OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] On Schemas, Namespaces and Syntax vs. Semantics (long but

[ Lists Home | Date Index | Thread Index ]

Dare Obasanjo wrote:

> Sending an XML document containg raw customer data without any extra semantic information is as useless as sending a fax without a cover sheet.

> If some executive fiat makes it mandatory that only raw customer data must sent which conforms to the shared schema then processing instructions can be embedded in the SOAP message which then indicate to the final receiver of the message what to do with each customer.

> Again, if the same executive fiat applies then the original customer data schema is written in such a way as to allow for W3C XML schema extensibility (wildcards,  xsi:type, substitution groups, abstract elements and types, redefinition etc) and each customer although conforming to the schema has enough identifying information that it is clear how the data should be processed.

> I prefer my solutions to Sam Ruby's because they clearly emphasize the "it's just data" aspect of XML instead of embedding accidental semantics where one wants only syntax and data.

Yes, one wants only syntax and data, but because "sending an XML document containing raw customer data without any extra semantic information is as useless as sending a fax without a cover sheet" you feel obliged to provide "enough identifying information that it is clear how the data should be processed" and you therefore see the 'problem' as how to " indicate to the final receiver of the message what to do". In my opinion, the problem is that the addressee of your message is not competent to process it, or at least you lack confidence that it will do so with the expertise you desire. Yet surely the point of a web of distributed services is that those services, or at least such of them as you would use, are
specifically expert in executing particular processes. It is for that specific expertise that you make use of those services rather than, say, creating analogous processes yourself to execute against your data in private within you own narrowly defined department or organization. With trusting such processes to bring such specific expertise to the handling of your data unavoidably comes the need to trust those processes to perform as they perform, precisely because you concede their expertise. Your fussy attempts to direct or control those processes in the execution of their own expertise are therefore at best otiose and in any case betray a fundamental lack of understanding of why you are sending your data in a
message to them.

Respectfully,

Walter Perry





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS