Friday, July 26, 2002

Schema & Semantics [In reference to this] I used the following example in a workshop today. Assume you do work for a bank. The bank has, of course, multiple departments and business divisions and we look at two of them for this: The first department is corporate loans. They create an XML Schema to exchange customer information about between the main branch and their satellite branches. The customer they are looking at is of course the companies they lend money to. The schema only covers the base customer information (name, adress, primary contacts, etc.). They are the first kid on the block to define such a Schema. "Fine! This Schema fits our need just well to exchange all base information about our customers with our branches, as well" says the financial collections division, which is indeed an independently operating business that serves its mother company's departments but also collects money for other customers.  Of course, and for proper separation of financials, they don't care much whether the customer is "internal" or external. Note that the customer term means two different things here. Not obvious? A customer of corporate loans doesn't meet two consecutive payment deadlines. So, the corporate loans department hands over their customer data as a SOAP wrapped document to the "EDI mailbox" (transport doesn't matter) of the financial collections business where it is queued for processing. Of course, at the same time, the usual swapping of customer data happens between the branches of the financial collections business and get queued for processing in that inbound queue. Now, the customer in the sense of corporate loans is a debtor for financial collections and corporate finance itself is a customer in the sense of financial collections. Now we have two documents with the same namespace but entirely different business semantics stuck in the same queue. What to do? You may say: Silly design! I say: Unnecessary and pointless limitation of design. When financial collections adopted the XML Schema they were supposed to assign a different namespace, because they associate radically different semantics with "customer". Had they done that, they could dispatch by semantics and schema identity; now, they need to provide different endpoints and make sure that everybody in the software development organisazion is aware that these seemingly same things are indeed very different things. That'd truly be silly, wouldn't it? [Executive summary: Those who only look at wire formats and are obsessed with loose coupling shall look at some more complex and real-world scenarios once in a while] [Author's note: The "customer" is an illustrative example to carry my point, but there are other, typically much simpler schemas, where such problems are even more likely to occur in the wild] 10:33:42 PM      comment []

DaveNet: Hollywood wants the right to hack your computer. In progress. [Scripting News]    This starts to look as if Orwell was right, just a bit early. To make things worse, the whole Homeland Security Dept. story sounds like similar things from a dark past to me. 7:34:43 PM      comment []

Sam Gentile is available for .NET, VSIP, COM and WS Work. Since Sam's doing this, I feel like I should throw in this shameless plug: We do architectural consulting, training content development, whitepapers and bootcamp & advanced training classes on .NET, XML, BizTalk and OOA/OOD and we indeed have a few spots in our calendar to fill this year. Bart is the right guy to talk to. Location doesn't matter, that's what Lufthansa is for.  In fact, I am thinking about writing up something a bit more (apart from the marketing speak on our website) on how we got to start newtelligence, what we've done before that, and on what we do and did recently. I get that question pretty often by a lot of people, so I figure that this is a good place to put it. 6:50:19 PM      comment []

Another thing from codaland (I don't see how someone obviously bright and having a sane message would want to stay anonymous, but...):  It'd be nice if it were possible to explictly declare in the document itself that 'My Schema derives from that Schema. Any document that conforms to My Schema probably conforms to that Schema'. This would probably solve 90% of the problems of moving XML documents between well-defined contexts, encourage extensibility and OO-design, and it would certainly be easier to use Schema/Namespace inheritance rather then writing an XSLT document for every imaginable context transition. Schema doesn't map to a class in OO. Schema maps to a namespace's content in OO and the XML-Namespace maps to that namespace's name. XSD does know imports and type-by-type inheritance, but that doesn't exist on a schema level.  Schema inheritance would be equivalent to deriving from a complete namespace and all of its classes in one shot in C#/C++. Schema describes just a bunch of types; the schema itself is just a scope which defines a common identity for a concrete set of concrete type definitions across space and time. This makes it necessary to change the identity of all types once one of them changes or the set changes. The practical benefit of OO inheritance (in my world) is that you get other people's stuff and if they fix their stuff or add to their stuff you get that new and fixed stuff, too. The other main benefit of polymorphism somewhat goes away if you have dynamic metadata. Dynamic metadata lets build generic infrastructures that don't look at class hierarchies, but just poke around in pieces metadata to determine whether and what stuff to do. That's where we are with things like Reflection (JVM & CLR), Attributes (CLR) and Schema (XML).  If you inherit Schema, the base Schema won't ever change. The benefit you are getting is that you are getting other people's stuff. You won't benefit from them fixing their stuff, because that'd change their Schema and hence that'd change your Schema. XSD doesn't really map to OO -- only very few aspects do. 7:34:53 AM      comment []

A comment from codaland on the ASP.NET state management stuff that I posted yesterday: The problem with this code is that it requires you derive all your classes from a common Page class. It'd be nicer if you could just stick an HTTP Module into the request pipeline and implement a marker interace (IStateManagedPage). I think I might make the necessary changes. There'll be problems with private variables. The comments for the Page class actually say that this stuff would be a lot better if there were generics (templates) in C#. So I do agree that the "must use this base class" thing is ugly. However, I don't think that the suggested workaround is any better and I believe that it even won't work, because the modules aren't triggered during the lifetime of the page (all of the page stuff happens between PreRequestHandlerExecute and PostRequestHandlerExecute); even if you hack it, you can't properly get to the page in a way that you can manage the page's state for all three cases (persistent, session, transient) that my class implements, because you need to get between the user and Redirect/Transfer for the transient scope. Private variables are intentionally not covered by this code, at all, and the comments say so. In my world, private variables are scoped to a class instance and therefore a page from roundtrip #1 shouldn't share them with the page from roundtrip #2, even if they're the same class serving the same user. 7:03:08 AM      comment []

Heh heh... Nice try. [Wrinkled Paper] Quote of the day: "Let's face it, System Administrators get no respect 364 days a year."  :-X   12:43:40 AM      comment []

© Copyright 2002 Clemens Vasters.