This is a summary of the complete story. It's a 5-part series.

I belive the author has a point in demonstrating that MS' Passport may have overreached (and the author does NOT slam MS just for the sake of slamming them). The SGML principles are the proper foundation for anything involving XML.

Again, it's long, but a worthy read.

WARNING! Pure Geek Material! WARNING!

where's my penguin ping?

Here it comes!

The Penguin Ping.

Wanna be Penguified? Just holla!

Got root?

Plan 9??? You mean this one?

It didn't work.

Oh, wait, sorry, wrong thread...

Oh, wait, sorry, wrong thread...

Yeah, I'd say so.

I'd say that there is a place for both solutions.

See, the problem is that the author is hanging all his criticism on one particular component of the .NET solution. There are likely to be emergant solutions to this issue that involve Web Services, and these -- almost by definition -- embrace XML closely.

I recently sat in on a debate where Geek #1 was ranting about how a proposed DTD wasn't pure SGML.

The response from Geek #2 was "The only people who give that big a rat's keister about SGML are the guys who maintain the SGML spec, and even THEY don't give that big a hoot."

The standards go both ways, Pooh. Take the W3C HTML standards. No one adheres to them to the letter, but it does provide more functionality to the user if all browsers at least had its underpinning on the W3C standards.

The same applies to XML. That's how I see it at least.

Okay, I looked at this thing closely. Here's my major problem with it:

They state that the factotum will handle all security interactions on the users behalf, and that the entire cryptographic exhange burden will be thusly lifted from both user programs and app developers alike.

Hel-LOOOOO....? Doesn't anyone see a problem with a remote process whos inner workings are not exposed 'handling' all the security and just issuing 'Gee he looks okay' messages? There is a huge security risk involved here! Any hacker worth his salt could knock out a factotum and then expose a web service with the same signature, and start issuing spurious acceptances.

I'm sorry; I like my cryptography to be nice and tightly-bound to the machine.

Standards are in place only so that we technical people can savage and mutilate them.

Standards are in place only so that we technical people can savage and mutilate them.

Standards were made to be ignored bump :o)

I'm sorry; I like my cryptography to be nice and tightly-bound to the machine.

I certainly can't argue with you there.

This I found intesting:

XML's roots go back to 1957

Like Passport, Dot.net is distantly based on a family of extensions to XML. I think of these extensions as the X-files; even Bishop Occam would want to blame vast government cover-ups of alien takeovers to explain the weird stuff we encounter in search of an explanation for Passport and dot.net ideas down the XML rabbit hole.

XML started out as a sort of simplified SGML (Structured General Markup Language, a 1983 ANSI standard) and originally inherited many of SGML’s key characteristics.

SGML defines how document-markup should be structured and unifies related ideas from both the printing and computing perspectives. On the editorial (or printing) side, SGML got its start the day after Gutenberg’s invention of movable type made it necessary to formalize editorial instructions to typesetters. From this perspective, SGML’s tags were instructional in nature, as in "start using 42 lines per page here".

On the computing-practices side, SGML’s roots only go back to about 1957. It was in this year that Rand Corp. made its first attempts to implement the COLEX text retrieval system, a development that led to the 1967 commercial release of SDC Dialog (probably (?) the first public-network-based information-service). COLEX was aimed at helping the U.S. Air Force sort through hundreds of thousands — maybe even millions — of technical documents, and it needed some way to differentiate text by type. As a result, COLEX tags were descriptive as in: TITLE: some title text :END_TITLE.

A third type of tag, combining formatting information with procedural information, was pioneered in early '60s MIT products like RUNOFF (which begat troff and ditroff). These tags were intentionally eschewed by the committee because SGML was intended to describe document markup, not document processing.

The SGML specification defines two types of information labeling:

data identification

presentation formatting

It does not say anything about data processing; for that you need an application that can interpret and act on SGML markup. That interpreter, in turn, has to drive some kind of output application that puts ink on paper or pixels on screens.

Consequently, the rigid separation of markup information from procedural information means that actual use of SGML needs three things:

You need to define what your tags are, what actions they translate to, and to what degree, if any, they can be nested. That set of definitions then constitutes the SGML document type to be produced when a document marked up using those tags is processed for formatting and is called, logically enough, a document type definition (DTD) An application that can interpret the markup and combine it with the document itself to produce output suitable for use as input to a rendering engine A graphics-output or rendering engine to produce the printed or displayed document.

The important thing here is that all of this is non-procedural: the markup tells the rendering engine what to do but not how to do it. In fact, the original ANSI committee made a special point of not including another computing tradition — that of fully integrated markup and processing languages like TROFF/TMac or the later LaTeX.

In general, the document-preparation workflow envisaged in SGML is:

Someone loads or creates the document source text Someone adds formatting and presentation information using a DTD (markup language) like HTML The completed document is stored On request, the markup language is interpreted by a transformer application which outputs graphics commands for a rendering engine The rendering application interprets the graphics commands to create the user readable output on screen or paper. Notice again that the only executables here are the transformer and rendering applications. The markup language is interpreted by the transformer and rendered by the graphics engine, but the markup language does not itself take on the attributes of a programming language and does not contain executable code.

How well this works in terms of final product quality depends in large part on the quality with which the output is rendered, something which itself depends on both the rendering application and the physical technology used.

The HTML DTD does not offer much direct formatting control; an HTML page displayed using IE on a PC with default fonts, borders, and window sizes will look very different than that same page displayed under Konqueror. What’s going on is that each browser has what amounts to an internal stylesheet that determines how text marked up with a format label like is actually rendered in the local graphics environment.

Cascading stylesheets bring better control where the page meets the PC screen by providing explicit rendering instructions to replace these default choices. For example, the browser default is to show something tagged

somewhat more than three font sizes bigger, but in the same color as, something tagged

but H1 { color:blue } over-rides the default stylesheet to add the instruction that text presented between

tags should also be rendered in blue.

Since a document can contain more than one set of rules either directly or by reference, some complexities arise in deciding which rules apply. In the official CSS specification, those inheritance rules are executed by sorting through presentation rules to find the nearest one not overridden by an "important" label attached to an instruction in a higher level stylesheet. This is a strategy roughly analogous to letting the person whose shouts sound loudest win the argument.

Graphically, this process can be presented as an inverted tree with formatting authority cascading down it to the lowest applicable level; hence, eventually, some more X-files: including Xpaths, Xlinks, Xschemas (done with the eXensible Stylesheet Definition Language [XSDL] or just .XSD in DOS), and, more recently, XMLNS or XML name-space files.

When work started in 1996 on yet another SGML DTD, to be known as XML, the need for stylesheets was a well-established part of commercial reality. Two additional standards, often grouped together under the name XSLFO (Extensible Stylesheet Language, Format Objects) and reasonably considered generalizations of the stylesheet concept, were co-developed with the XML specification to accommodate this.

I certainly can't argue with you there.

You're hired.

You're hired.

Hey! I'm now Laz's resident "Yes man!"

Now, about wages. I accept nothing less than $75/hour. ;-)

Now, about wages. I accept nothing less than $75/hour. ;-)

You're fired.

:-|