Getting a schema for mssecure.xml with "infer"

alexk — Sat, 11 Oct 2003 10:46:00 GMT

[Listening to: Mozart - Fur Elise (03:34)]

While looking for a way to handle patch management mini-tasks, I ran across the following response by a Microsoft employee to a request for the schema for mssecure.xml (in context, the softie did not sound happy about having to give this kind of answer):
Microsoft doesn't publish the schema for the MSSECURE.XML file. We reserve the right to modify, change and update the schema as necessary to enhance products that rely on and use the MSSECURE.XML file.
That's not precisely true. Microsoft does publish a schema, an implicit one. What people tend to forget is that any well-formed XML file conforms to a schema. It may not be a formal one or even an appropriate one, but a schema can be inferred from that XML file instance.
Of course, no one wants to spend hours trying to determine a schema from a 1.7 MiB file. If you get Microsoft's own xsdinfer tool, though, you can automatically parse the schema in seconds.
I proceeded to do that with the latest (2003-10-03) mssecure.xml and I have made the inferred mssecure.xsd file available as a zipped download.
Note that this is incredibly easy to do. I simply ran
infer mssecure.xml -o mssecure and had mssecure_1.xsd ready in seconds. The schema is very clean considering the size of mssecure.xml; it reduces to 11.8 KiB and compresses to 1.7 in the download.

.NET and Console Tools - We're Getting There, But...

alexk — Fri, 10 Oct 2003 21:21:00 GMT

[Listening to: We Have Explosive - The Future Sound of London - We Have Explosive (03:26)]

I've been going through Visual Basic .NET 2003 Resource Kit this morning, looking for goodies I can reuse elsewhere. One of the "metrics" I use is how good console tool support is.
Strictly speaking, this is not a VB issue, it is a .NET issue, and I'm finding myself wandering off to think about the whole issue of console tool support as a concept in Windows systems. The real underlying problem is not one of what classes are available here and there for console tools. The problem is that programmers don't usually realize that a console application is to an administrator what a class is to a programmer.
A CLI application is really a component, and to be the best at what it does, it needs to be self-contained, use common switches, and understand working with stream for input, output, and error. It needs to be self-describing as well, so that help is just moments away.
I'm not quite sure what the "best" answer is, but there is no doubt that a core library which allows simple, single-step generation of help text and internal primitives for scripts and for compiled applications could make an immense difference to the growth of well-behaved, admin-friendly building block applications.

Administrative Scripting : Consolation for commandline users

Getting a schema for mssecure.xml with "infer"

.NET and Console Tools - We're Getting There, But...