[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote :
>In a loosely coupled application you may know very little
>about the data other than it is well-formed XML, and the job
>of an application component is to extract whatever
>information APPEARS to match the patterns it is looking for,
>put the information in a more useable form, and pass it down
>the pipeline for further processing. A network of these
>simple components can do some quite interesting things, and
>tools such as Sean McGrath's XPipe stuff and Software AG's
>EntireX Orchestrator are becoming available to develop them.
>
>This is a very different way of looking at XML (and data
>processing for that matter) than the object-centric or
>schema-centric approach. It solves one problem -- the lack
>of authoritative schema for many application domains -- by
>accepting a lot more chaos and error than many might find
>tolerable. In any real system, there would have to be humans
>involved to make sure that that purchase order that looks
>like the deal of a lifetime is indeed what the pattern
>matcher thought it was and not a joke, a fraud, or something
>else entirely. But at least they won't reject the purchase
>order of a lifetime because it had an extra <p> tag
>somewhere. <grin, yeah I know this is a contrived example!>
>More seriously, this is a way to exploit what order there is
>in the system, i.e., an <invoice> tag probably refers to
>something resembling an "invoice", without insisting on total
>conformity.
>
>This is not to say that this "loose" approach is the best;
>it's certainly not when you CAN authoritatively specify fixed
>schemas and reject messages/documents that don't match them.
>But it's better than handwringing about how XML can only be
>used once everyone agrees on a schema for some particular
>industry, as we see so often in the trade press.
In that case, you drop the validity constraint and try to do some "fuzzy"
pattern matching : 'I received an <facture> element, "facture" is the french
for "invoice", so I'll apply my "invoice" fuzzy logic, so I'll have to find
product, amount and unit price somewhere, but what's the french for amount,
anyway ?'.
No, your "fuzzy" logic can't be that fuzzy, you'll have to restrict a little
bit the range of documents you can accept. And guess what ? By restricting
this range, you'll define an operational schema, and implicit or explicit
schema that is used to process incoming data. This schema will certainly
contain "holes", <xsd:all> patterns, or even some more "fuzzy" patterns
(such as 'foo//bar' in XPath, for which I don't know if there is an
equivalent in XML Schema or RELAX NG), but it will be a schema nonetheless.
Regards,
Nicolas
|
