Remembering the Future

You have some XML you want to process using XmlSerializer, but you don't have a schema to feed to xsd.exe in order [to] generate CLR types. So what do you do? Write your serializable class by hand. It isn't very hard once you understand the basic mapping. Here's how it works.

Article Summary: Illustrates a new way of building dynamic user interfaces that automatically respond to changes in a data model and update their appearance by using binding relationships between the elements in the UI. This example uses a 100% XAML approach to demonstrate these relationships, called "bindings".

Download the code for this tutorial

The Pluralsight folks were kind enough to give me wiki space.

Here's the link: http://pluralsight.com/wiki/default.aspx/Don.HomePage

Keith Brown is moving his new security book into a Wiki

InfoWorld has been noticing a lot of congestion at the top of the hour when thousands of RSS clients all hit our servers simultaneously to check for updated feeds. We've done a number of things to alleviate this, but thanks to excellent feedback from the RSS community we've done a lot more today that will hopefully resolve some of these issues.

This article shows how to use the XmlDiff class to compare two XML files and show these differences as an HTML document in a .NET Framework 1.1 application. The article also shows how to build a WinForms application for comparing XML files.

Congratulations to Scott Johnson and the rest of the Feedster gang for the launch of Feedster version 2. There are lots of new features to digest, but the ones that most interest me are those that enhance cross-blog conversation.

The Semantic Web has a serious problem: the XML people don't understand it.

They think it's an utterly complex way to write metadata that you can do with simple namespaces. The two worlds (despite being both hosted inside W3C) don't talk very much. Many (if not all) W3C folks are all in the RDF camp (and have been there for a while) and they see XML as a half-baked attempt to solve issues that RDF already solves. Unfortunately, not having been in the XML camp at all, they have no way to communicate with the other side.

The XML camp, on the other hand, thinks that they know how to build things that work, while the RDF people are all sitting in their ivory towers telling them that what they are doing is wrong, but without understanding their real-world needs.

As it normally happens in a debate, both are right and both are wrong.

I find myself sitting in a very lucky position: right in the middle of both camps and I talk to both of them.

So, this is a RDF guide for XML people. A much needed one, IMO.

I'll keep the updated list of posts relating to performance in XML manipulation here.

Check out the whole "High-performance XML" series:

• High-performance XML (I): Dynamic XPath expressions compilation
• High-performance XML (II): XPath execution tips
• High-performance XML (II'): Enhance XPath execution performance with XPathCache
• High-performance XML (III): returning well-formed XML from WebServices without XmlDocument
• High-performance XML (IV): subtree transformations without re-parsing
• High-performance XML (V): in-memory XML Schema validation without re-parsing

posted on Friday, July 09, 2004 10:16 AM

• Things too simple are difficult
• Things too complex are difficult
• Human thoughts are not simple
• Programs are essentially complex
• Combination of simple concepts can be complex very easily

• Principle of fulfilled expectation
• Principle of pleasant surprise
• Principle of Immersion

• wasting time
• can't focus on problem
• are interrupted

Languages can be viewed as interfaces

Guidelines for good interfaces.

• Consistency
• Flexibility
• Succinctness

Programming languages are the box outside of which most programmers, architects, and managers cannot think. Languages, for them, are things you choose, not things you build. When language specialists see simple solutions, the untrained see costly problems that will remain unaddressed.

We currently give you three "full-featured" ways to send a message from one process to another: MSMQ, DCOM, HTTP. I don't discuss .NET Remoting's binary/tcp protocol, as for one, it's not secure, and secondly, DCOM is typically faster. All three mechanisms allow you to send a secured and structured message from one program to another, including programs running on other machines.

All three mechanisms have rich programmatic support and again, what's interesting is how they differ.

Services and Processes

We currently give you three ways to get a process up and running: NT SCM, COM(+) SCM, and the IIS6 WAS.

All three mechanisms allow you to configure a deployed piece of code to start as a particular user account or one of the three service accounts (NetworkService/LocalService/LocalSystem).

All three mechanisms have programmable access to management and configuration. What's interesting is how they differ.

I define a smart client application as a rich user interface application that resides on the client in a secure manner, connected to a back-end server, and is deployed over http.

Let's break that statement into its elements:

"Rich user interface" means Widows-based user interface. Users simply prefer rich user interface. They dislike the dull interface of the web. They want floating toolbars, graphics and 3D grids, that they can edit in-place, without clicking through dozens of web forms. The only way to do that using managed code today is using Windows Forms.

"In a secure manner" means it uses code-access security, to enable secure execution and deployment, provide the user with a consistent experience – regardless whether they try to access files, run scripts, download EXEs or controls, they will not be able to shoot themselves in the foot yet they can get a workable and usable application. There is no need for runtime user decision ("Do you trust all content coming from so and so..").

"Connects to a backend server" means that you would want to have the actual logic in one centralized place. In most scenarios where calling to the server involves crossing boundaries, web services will make the most sense. Boundaries can mean a security boundary (firewall, or domain trust), team boundary, component technology boundary, operating system, geographical boundary, etc.   

"Deployed over http" means no-touch-deploy, ClickOnce, or any web server (not necessarily IIS) capable of servicing the download. This is essential to overcoming internal IT groups resistance to deploying applications to numerous end-stations.