Slashdot Mirror

Actually, the opposite is what happens: sell prices are minimized while buy prices are maximized. That's the whole point, they make their money in the difference...

Exactly. It's just a legalized form of the salami swindle.

http://zvon.org/comp/r/ref-Security_Glossary.html#Terms~salami_swindle

Haskell allows you to define new binary operators trivially, and set/override the precedence and associativity of operators (/w "fixity" declarations). Haskell assumes that a function name consisting entirely of symbols is meant to be used as an operator. You can even apply a function infix style using backquotes, e.g. "3 `func` 4" (yes, you can define precedence and associativity for those too).

OTOH, Haskell is very different from most languages (in a good way, IMO), being pure functional, lazy and statically typed. It's definitely not a drop-in replacement for C++ or Java.

I'll grant you that tables are often employed to do what cross-platform CSS seemingly can not; yet, there are also behaviors CSS can do that are not possible with tables.

Yet, I will stipulate that CSS alone can often emulate, or even improve upon, the cumulative effect of rigid-table design. (even without using the DreamWeaver "layer" implementation, though I believe it will ultimately come around anyway)

The explanation I hear again and again is that Table v. CSS is a "high-road, low-road" paradigm. They both have the ability to get you to the same place, though each takes its own route to get there. I found one such example here.

For myself, I see that CSS has the room to expand into a complete layout solution.

The use of tables is dated, and its days are numbered. Tables are just a convenience derived from an element that was intended only to arrange text. (hence the name "table" and not "grid" or "layout") The complications with tables often arise in asymmetrical and non-gridded usage; something tables were not expected to do very often. (note section #4)

Tables are the old horse, and the scars of being incessantly whipped have been showing for some time. While it's not the same-old way we're used to, CSS layout practices are slowly becoming both more "fashionable" and more common in professional publications.

Someone once said that the rate of growth of banana spots can be accurately modeled with the Avrami Equation http://gold.zvon.org/A00545.html

1. the whole "genius" of client-side xslt is it makes the client do work that would otherwise drag the server. my server just spits out naked xml. the server is stripped down in its workload to the most naked thing you need the server for: raw data. you don't even need a webserver. you just need a database plugged into port 80 ;-P (well, not really, but you get my point)

the client has to do all the heavy sorting and formatting work to make it pretty and readable. i like that scheme. a lot. i call it K.I.S.S. Keep It Simple Stupid. put that up there with Ajax in terms of development paradigms which mean something significant to me, for whatever that is worth. and in fact i think this KISS will only get more and more popular as a development approach. even though i find people are put off by xslt. but it REALLY isn't that complicated. here's an excellent tutorial

you don't even have to mess with javascript transforms (well, you do, if you want an interactive site, i'm just talking you don't need to use javascript in your development scheme to get bare functionality, to get the paradigm that works here). it's really the same idea as html + css, except it takes the idea of content versus formatting to an even deeper level of separation: raw data versus all the markup, pushing all the markup to the client. so if you dig why css is so important, you'll understand my reluctance to server-side my xslt

to me, asking me to server-side the xslt is like asking me to get rid of all css and format each tag individually. bleh. no thanks. more work, slower performance, heavier on the wire

2. great news on opera 9 ;-) now i can code with even more confidence that i'm on the right path

watch this idea: xml + client-side xslt. KISS to me. raw data only from the server, and all formatting on the client side. even though it's an ancient idea, i think it will be just like with AJAX, which was ALSO an ancient idea that just suddenly got a massive thrust in terms of modern development interest

In fact, they're so non-unique that the HTTP protocol actually specifically points out that method=POST, PUT, and DELETE should not be retried. Also, I can't find the reference, but most browsers won't cache passwords when you go back and then forwards, as a security precaution, and that's basically standard practice. The back button has LONG been broken.

That doesn't mean we should ignore the criticisms of AJAX, but I think the take-home message should more be "be aware that there are these downsides, and web authors should everything they can to minimize those downsides. In some situations, this may mean using a simpler method than AJAX. However, AJAX as a whole is something that is beneficial, rather than harmful."

It's an internal feature called 'dump-emacs':

http://www.zvon.org/other/elisp/Output/SEC661.html

I don't use it because a). I usually run emacs in X11 and it apparently doesn't work well outside of console mode, and b). I leave emacs running 24/7 and use gnuserv to 'send' files to it (e.g. clicking on a .c file in a file browser is configured to run gnuserv which opens the file as a new buffer in an existing emacs session) so I don't require fast startup.

It's not a very usable feature I'm afraid, but I did try it once or twice and thought "cool, I must remember that"... :)

You are correct about the problems with TCP, and its one that my company has had to look at for it's new series of satellite services. If left alone TCP/IP really slows down and modifying window size and slow start parameters only helps a little bit.

One possible solution is to fiddle with the protocol supplying fake ACKs from machines on either side of the link and relying on your own error detection/correction protocols over the satellite link. Take a look at RFC 3135 - this describes different types PEPs that can be used for varying channel conditions.

Well if you are planning to write a Firefox extension, I won't feel too guilty about suggesting things that "someone" should implement. The thought that occured was that people will mostly get spoofed by immitations of sites they have previously visited - their bank, paypal etc.

You could check the url against urls in the browser's history, and look for domains that almost match - this being defined as only differing by characters that appear similar. If it is an almost match, flag it to the user, who could whitelist it (I do think having an option to flag all non-ascii urls is a good idea though).

So páypal.xxx would flag up a warning if the user had previously visited paypal.com (although I suppose that a blacklist would be better for commonly spoofed sites, ideally).

As for matching the characters, I found this, which can be downloaded from here - there's a file called chars.xml in the zip which has all the letters in the alphabet in nice xml.

If/When/(have they already?) non-standard characters start to be used for many comercial sites, this system would cope without many false positives, since it would only signal the user if they had visited an almost matching version first.

This is by no means foolproof I guess - a dodgy paypal sign up link could fool a non-paypal user if they wanted to buy something for example. In theory though this could be combined with a blacklist of high-risk domains, which would always be flagged up. (List should maintained by "someone".)

Just an idea, and maybe a bad one, but I thought I'd suggest it since I'm far too lazy to try to do it myself..

Well if you are planning to write a Firefox extension, I won't feel too guilty about suggesting things that "someone" should implement. The thought that occured was that people will mostly get spoofed by immitations of sites they have previously visited - their bank, paypal etc.

You could check the url against urls in the browser's history, and look for domains that almost match - this being defined as only differing by characters that appear similar. If it is an almost match, flag it to the user, who could whitelist it (I do think having an option to flag all non-ascii urls is a good idea though).

So páypal.xxx would flag up a warning if the user had previously visited paypal.com (although I suppose that a blacklist would be better for commonly spoofed sites, ideally).

As for matching the characters, I found this, which can be downloaded from here - there's a file called chars.xml in the zip which has all the letters in the alphabet in nice xml.

If/When/(have they already?) non-standard characters start to be used for many comercial sites, this system would cope without many false positives, since it would only signal the user if they had visited an almost matching version first.

This is by no means foolproof I guess - a dodgy paypal sign up link could fool a non-paypal user if they wanted to buy something for example. In theory though this could be combined with a blacklist of high-risk domains, which would always be flagged up. (List should maintained by "someone".)

Just an idea, and maybe a bad one, but I thought I'd suggest it since I'm far too lazy to try to do it myself..

Othere than SPF, there is no sane reason for most DNS servers to issue TXT records.

Really? What rock have you been hiding under?

There is nothing that SPF does that DNSBL like systems can't do better using existing software and normal data packets.

I haven't yet seen a DNSBL system that says authoritatively that a given IP is allowed to send email for a certain domain, much less with the same kind of flexibility that is allowed in SPF.

Zvon is the greatest resource for CSS and XHTML. These two links are all I ever need.

CSS click "Properties - all"
XHTML lets you know which tags can be parents or children of each other and which attributes are valid in the Strict, Transitional, or Frameset DTDs.

Zvon is the greatest resource for CSS and XHTML. These two links are all I ever need.

CSS click "Properties - all"
XHTML lets you know which tags can be parents or children of each other and which attributes are valid in the Strict, Transitional, or Frameset DTDs.

/. people should know better than most that you can't retroactively flip a security bit and make past mistakes better...

Au contraire...
RFC 3514 -- Security Flag in the IPv4 Header
You may not be able to flip a bit, but you can always just detect one. ;-)

You forgot to include a decent reference.

Besides, don't you want to hear some poor sod's server scream out its last dying breath early on a Monday morning? Ahh... better than fresh coffee.

and other goodies at zvon.org. The DOM specs at the W3 site really seem like they are for implementors rather than users.

I am still looking for a good, up to date tutorial on CSS (recommendations welcome).

I am still looking for a good, up to date tutorial on CSS (recommendations welcome).

I am still looking for a good, up to date tutorial on CSS (recommendations welcome).

I am still looking for a good, up to date tutorial on CSS (recommendations welcome).

Another excellent source for such information is zvon .

handy link on 0.0.0.0

Good link, thanks! Right to the point, lots of good links off it. If i had a mod point I would give it to you. Or a beer.

handy link on 0.0.0.0

IP over Avian Carriers with Quality of Service? Do I feed the pigeons spoiled grain, and let the receiver analyze the poop? Do I spraypaint them black? What if they're black already - do I spraypaint them white?

Clearly, this RFC needs a lot of work to integrate it into the Internet we've come to know and love.

Why pay to block ads? They are dead on the web! Simply run Privoxy. Combine it with Transproxy and you'll be able to block all ads on the web. Especially combined with the regex know how of Regular Expressions Tutorial.

Since then, there's been some loose talk about the "tragedy of the commons" from people who know a little economics but not much network design. These people usually seem to have a bias in favor of markets as a solution to a wide range of problems. Their arguments are not compelling.

Sometimes a market isn't the solution. The feedback loops implicit in a pricing model are usually far too slow to regulate a datagram network without introducing instability. Realize that markets are control systems, and are subject to the stability problems of control systems. Most economists don't get this. Classical economics assumes that if there's an equilibrium point, the system will stabilize at or near it. That's not true; all you're really guaranteed is that if it oscillates, the oscillations will pass through the equilibrium point now and then.

In addition, a pricing system itself imposes costs. In telephony, billing now costs more than transmission. Billing, setup, and support typically cost an ISP more than their backbone bandwidth. There's so much underutilized fibre installed now that backbone bandwidth just isn't a problem.

Most of this talk is an attempt to justify a price increase by an incumbent monopoly.

A couple of search terms that you'd never come up with if you weren't already steep in the the arcane x.500 world: ISODE and quipu.

Most of this stuff comes out of and is maintained in Europe. As the RFC 1330 says,
"The ISODE is not proprietary, but it is not in the public
domain. This was necessary to include a "hold harmless"
clause in the release. The upshot of all this is that anyone
can get a copy of the release and do anything they want with
it, but no one takes any responsibility whatsoever for any
(mis)use."

You can still find the latest downloads via FUNET.

Be aware, this stuff is a major effort to compile and get working. It's big and complex, but well documented. Have fun, and let me know when you get dish -user "@c=$(COUNTRY)@o=ORG@cn=Manager" to give you a prompt.

This article explores the ins and outs of XML namespaces and their ramifications on a number of XML technologies that support namespaces. What follows is a shortened version of my first Extreme XML column.

As XML usage on the Internet became more widespread, the benefits of being able to create markup vocabularies that could be combined and reused similarly to how software modules are combined and reused became increasingly important. If a well defined markup vocabulary for describing coin collections, program configuration files, or fast food restaurant menus already existed, then reusing it made more sense than designing one from scratch. Combining multiple existing vocabularies to create new vocabularies whose whole was greater than the sum of its parts also became a feature that users of XML began to require.

However, the likelihood of identical markup, specifically XML elements and attributes, from different vocabularies with different semantics ending up in the same document became a problem. The very extensibility of XML and the fact that its usage had already become widespread across the Internet precluded simply specifying reserved elements or attribute names as the solution to this problem.

The goal of the W3C XML namespaces recommendation was to create a mechanism in which elements and attributes within an XML document that were from different markup vocabularies could be unambiguously identified and combined without processing problems ensuing. The XML namespaces recommendation provided a method for partitioning various items within an XML document based on processing requirements without placing undue restrictions on how these items should be named. For instance, elements named <template>, <output>, and <stylesheet> can occur in an XSLT stylesheet without there being ambiguity as to whether they are transformation directives or potential output of the transformation.

An XML namespace is a collection of names, identified by a Uniform Resource Identifier (URI) reference, which are used in XML documents as element and attribute names.

A namespace declaration is typically used to map a namespace URI to a specific prefix. The scope of the prefix-namespace mapping is that of the element that the namespace declaration occurs on as well as all its children. An attribute declaration that begins with the prefix xmlns: is a namespace declaration. The value of such an attribute declaration should be a namespace URI which is the namespace name.

Here is an example of an XML document where the root element contains a namespace declaration that maps the prefix bk to the namespace name urn:xmlns:25hoursaday-com:bookstore and its child element contains an inventory element that contains a namespace declaration that maps the prefix inv to the namespace name urn:xmlns:25hoursaday-com:inventory-tracking.

In the above example, the scope of the namespace declaration for the urn:xmlns:25hoursaday-com:bookstore namespace name is the entire bk:bookstore element, while that of the urn:xmlns:25hoursaday-com:inventory-tracking is the inv:inventory element. Namespace aware processors can process items from both namespaces independently of each other, which leads to the ability to do multi-layered processing of XML documents. For instance, RDDL documents are valid XHTML documents that can be rendered by a Web browser but also contain information using elements from the http://www.rddl.org namespace that can be used to locate machine readable resources about the members of an XML namespace.

It should be noted that by definition the prefix xml is bound to the XML namespace name and this special namespace is automatically predeclared with document scope in every well-formed XML document.

The previous section on namespace declarations is not entirely complete because it leaves out default namespaces. A default namespace declaration is an attribute declaration that has the name xmlns and its value is the namespace URI that is the namespace name.

A default namespace declaration specifies that every unprefixed element name in its scope be from the declaring namespace. Below is the bookstore example utilizing a default namespace instead of a prefix-namespace mapping.

All the elements in the above example except for the inv:inventory element belong to the urn:xmlns:25hoursaday-com:bookstore namespace. The primary purpose of default namespaces is to reduce the verbosity of XML documents that utilize namespaces. However, using default namespaces instead of utilizing explicitly mapped prefixes for element names can be confusing because it is not obvious that the elements in the document are namespace scoped.

Also, unlike regular namespace declarations, default namespace declarations can be undeclared by setting the value of the xmlns attribute to the empty string. Undeclaring default namespace declarations is a practice that should be avoided because it may lead to a document that has unprefixed names that belong to a namespace in one part of the document, but don't in another. For example, in the document below only the bookstore element is from the urn:xmlns:25hoursaday-com:bookstore while the other unprefixed elements have no namespace name.

This practice should be avoided because it leads to extremely confusing situations for readers of the XML document. For more information on undeclaring namespace declarations, see the section on Namespaces Future.

A qualified name, also known as a QName, is an XML name called the local name optionally preceded by another XML name called the prefix and a colon (':') character. The XML names used as the prefix and the local name must match the NCName production, which means that they must not contain a colon character. The prefix of a qualified name must have been mapped to a namespace URI through an in-scope namespace declaration mapping the prefix to the namespace URI. A qualified name can be used as either an attribute or element name.

Although QNames are important mnemonic guides to determining what namespace the elements and attributes within a document are derived from, they are rarely important to XML aware processors. For example, the following three XML documents would be treated identically by a range of XML technologies including, of course, XML schema validators.

The W3C XML Path Language recommendation describes an expanded name as a pair consisting of a namespace name and a local name. A universal name is an alternate term coined by James Clark to describe the same concept. A universal name consists of a namespace name in curly braces and a local name. Namespaces tend to make more sense to people when viewed through the lens of universal names. Here are the three XML documents from the previous example with the QNames replaced by universal names. Note that the syntax below is not valid XML syntax.

To many XML applications, the universal name of the elements and attributes in an XML document are what is important, and not the values of the prefixes used in specific QNames. The primary reason the Namespaces in XML recommendation does not take the expanded name approach to specifying namespaces is due to its verbosity. Instead, prefix mappings and default namespaces are provided to save us all from developing carpal tunnel syndrome from typing namespace URIs endlessly.

Namespace declarations do not apply to attributes unless the attribute's name is prefixed. In the XML document shown below the title attribute belongs to the bk:book element and has no namespace while the bk:title attribute has urn:xmlns:25hoursaday-com:bookstore as its namespace name. Note that even though both attributes have the same local name the document is well formed.

In the following example, the title attribute still has no namespace and belongs the book element even though there is a default namespace specified. In other words, attributes cannot inherit the default namespace.

A namespace name is a Uniform Resource Identifier (URI) as specified in RFC 2396. A URI is either a Uniform Resource Locators (URLs) or a Uniform Resource Names (URNs). URLs are used to specify the location of resources on the Internet, while URNs are supposed to be persistent, location-independent identifiers for information resources. Namespace names are considered to be identical only if they are the same character for character (case-sensitive). The primary justification for using URIs as namespace names is that they already provide a mechanism for specifying globally unique identities.

The XML namespaces recommendation states that namespace names are only to act as unique identifiers and do not have to actually identify network retrievable resources. This has led to much confusion amongst authors and users of XML documents, especially since the usage of HTTP based URLs as namespace names has grown in popularity. Because many applications convert such URIs to hyperlinks, it is irritating to many users that these "links" do not lead to Web pages or other network retrievable resource. I remember one user who likened it to being given a fake phone number in a social situation.

One solution to avoid confusing users is to use a namespace-naming schema that does not imply network retrievability of the resource. I personally use the urn:xmlns: scheme for this purpose and create namespace names similar to urn:xmlns:25hoursaday-com when authoring XML documents for personal use. The problem with homegrown namespace URIs is that they may run counter to the intent of the Names in XML recommendation by not being globally unique. I get around the globally unique requirement by using my personal domain name http://www.25hoursaday.com as part of the namespace URI.

Another solution is to leave a network retrievable resource at the URI that is the namespace name, such as is done with the XSLT and RDDL namespaces. Typically, such URIs are actually HTTP URLs. A good way to name such URLs is by using the format favored by the W3C, which is as follows:

See the section on Namespaces and Versioning for more information on using similarly structured namespace names as a versioning mechanism.

The W3C has defined a number of technologies that provide a data model for XML documents. These data models are generally in agreement, but sometimes differ in how they treat various edge cases due to historic reasons. Treatment of XML namespaces and namespace declarations is an example of an edge case that is treated differently in the three primary data models that exist as W3C recommendations. The three data models are the XPath data model, the Document Object Model (DOM), and the XML information set.

The XML information set (XML infoset) is an abstract description of the data in an XML document and can be considered to be the primary data model for an XML document. The XPath data model is a tree-based model that is traversed when querying an XML document and is similar to the XML information set. The DOM precedes both data models but is also similar to both data models in a number of ways. Both the DOM and the XPath data model can be considered to be interpretations of the XML infoset.

The XML namespace section of the DOM Level 3 specification considers namespace declarations to be regular attribute nodes that have http://www.w3.org/2000/xmlns/ as their namespace name and xmlns as their prefix or qualified name.

Elements and attributes in the DOM have a namespace name that cannot be altered after they have been created regardless of whether their location within the document changes or not.

The W3C XPath recommendation does not consider namespace declarations to be attribute nodes and does not provide access to them in that capacity. Instead, in XPath every element in an XML document has a number of namespace nodes that can be retrieved using the XPath namespace navigation axis.

Each element in the document has a unique set of namespace nodes for each namespace declaration in scope for that particular element. Namespace nodes are unique to each element in that namespace. Thus namespace nodes for two different elements that represent the same namespace declaration are not identical.

The XML infoset recommendation considers namespace declarations to be attribute information items.

In addition, similar to the XPath data model, each element information item in an XML document's information set has a namespace information item for each namespace that is in scope for the element.

The W3C XML Path Language also known as XPath is used to address parts of an XML document and is used in a number of W3C XML technologies including XSLT, XPointer, XML Schema, and DOM Level 3. XPath uses a hierarchical addressing mechanism similar to that used in file systems and URLs to retrieve pieces of an XML document. XPath supports rudimentary manipulation of strings, numbers, and Booleans.

The XPath data model treats an XML document as a tree of nodes, such as element, attribute, and text nodes, where the name of each node is a combination of its local name and its namespace name (that is, its universal or expanded name).

For element and attribute nodes without namespaces, performing XPath queries is fairly straightforward. The following program, which can be used to query XML documents using the command line, shall be used to demonstrate the impact of namespaces on XPath queries.

Given the following XML document that does not declare any namespaces, queries are fairly straightforward as seen in the examples following the code.

xpathquery.exe bookstore.xml /bookstore/book/title

Selects all the title elements that are children of the book element whose parent is the bookstore element, which returns:
<title>The Autobiography of Benjamin Franklin</title>
<title>The Confidence Man</title>

xpathquery.exe bookstore.xml //@genre

Select all the genre attributes in the document and returns:
genre="autobiography"
genre="novel"

xpathquery.exe bookstore.xml //title[(../author/first-name = 'Herman')]

Selects all the titles where the author's first name is "Herman" and returns:
<title>The Confidence Man</title>

However, once namespaces are added to the mix, things are no longer as simple. The file below is identical to the original file except for the addition of namespaces and one attribute to one of the book elements.

Note that the default namespace is in scope for the whole XML document, while the namespace declaration that maps the prefix bk to the namespace name urn:xmlns:25hoursaday-com:bookstore is in scope for the second book element only. Example 2

xpathquery.exe bookstore.xml /bookstore/book/title

Selects all the title elements that are children of the book element whose parent is the bookstore element, which returns NO RESULTS.

xpathquery.exe bookstore.xml //@genre

Selects all the genre attributes in the document and returns:
genre="autobiography"
genre="novel"

xpathquery.exe bookstore.xml //title[(../author/first-name = 'Herman')]

Selects all the titles where the author's first name is "Herman," which returns NO RESULTS.

The first query returns no results because unprefixed names in an XPath query apply to elements or attributes with no namespace. There are no bookstore, book, or title elements in the target document that have no namespace. The second query returns all attribute nodes that have no namespace. Although namespace declarations are in scope for both attribute nodes returned by the query, they have no namespace because namespace declarations do not apply to attributes with unprefixed names. The third query returns no results for the same reasons the first query returns no results.

The way to perform namespace-aware XPath queries is to provide a prefix to namespace mapping to the XPath engine, then use those prefixes in the query. The prefixes provided do not need to be the same as the namespace to prefix mappings in the target document, and they must be non-empty prefixes. Example 3

xpathquery.exe bookstore.xml /b:bookstore/b:book/b:title b urn:xmlns:25hoursaday-com:bookstore

Select all the title elements that are children of the book element whose parent is the bookstore element and returns the following:
<title xmlns="urn:xmlns:25hoursaday-com:bookstore">The Autobiography of Benjamin Franklin</title>
<bk:title xmlns:bk="urn:xmlns:25hoursaday-com:bookstore"> The Confidence Man</bk:title>

xpathquery.exe bookstore.xml //@b:genre b urn:xmlns:25hoursaday-com:bookstore

Selects all the genre attributes from the "urn:xmlns:25hoursaday-com:bookstore" namespace in the document that returns:
bk:genre="fiction"

xpathquery.exe bookstore.xml //bk:title[(../bk:author/bk:first-na me = 'Herman')] bk urn:xmlns:25hoursaday-com:bookstore

Selects all the titles where the author's first name is "Herman" and returns:
<bk:title xmlns:bk="urn:xmlns:25hoursaday-com:bookstore"> The Confidence Man</bk:title>

Note This last example is the same as the previous examples but rewritten to be namespace aware.

For more information on using XPath, read Aaron Skonnard's article Addressing Infosets with XPath and view the examples at the ZVON.org XPath tutorial.

The W3C XSL transformations (XSLT) recommendation describes an XML-based language for transforming XML documents into other XML documents. XSLT transformations, also known as XML style sheets, utilize patterns (XPath) to match aspects of the target document. Upon matching nodes in the target document, templates that specify the output of a successful match can be instantiated and used to transform the document.

Support for namespaces is tightly integrated into XSLT, especially since XPath is used for matching nodes in the source document. Using namespaces in your XPath expressions inside XSLT is much easier than using the DOM.

The example that follows contains:

A program for use in executing transforms from the command line.

An XSLT stylesheet that prints all the title elements from the urn:xmlns:25hoursaday-com:bookstore namespace in the source XML document when run against the bookstore document from the urn:xmlns:25hoursaday-com:bookstore namespace.

The resulting output. Program Imports System.Xml.Xsl

I find zvon.org to be a great site for understanding w3 standards (including XSLT). The tutorials are just sequences of examples; they get straight to the point.

Short answer: it is a LOT more work up front. But later it is sweet. You let your graphic stud come up with a new layout in HTML (dreameweaver or whatever) and you write an XSL to translate into that. Maybe have him export a netscape compatible one (browser sniffing dishes out a different transform) and you have a plain text one as well (section 508 compliance becomes very easy. That's what is driving the current conversion).

Thanks for the info. The correct url is http://www.zvon.org/xxl/XSLTreference/Output/index .html. Unfortunately, it sounds exactly like what I thought. Just another way of doing something, not necessarily better :(

We use HTML templates for everything, where you basically have HTML with variables in it, that get replaced by the code. It gets complicated when you tables and such, or when you do anything that changes the ordering of the templates. That's what I haven't been able to find a good way of doing: specifying a template order separate from the code, while using templates that are displayed by code (such as displaying all rows in a table). Though you don't change the entire layout too often, and when you do, it's not that much code to change. I can see the advantage to using XML and XSL for everything, but it seems that it might be easier to just change the little bit of code necessary when changing layouts.

Try Zvon. http://www.zvon.org. They are a great site that is regularly updated.

PS: I was a tech editor for XML in a Nutshell, so it's really cool to see it reviewed here :-)