U.S. House of Representatives Makes Resolutions in XML

RennieScum writes: "The House of Representatives is turning to technology with their test of XML for use with resolutions according to this article. It reports that the HR has made 100 DTDs and uses Microsoft Word and a special converter to do the job. Testing has begun and their goal is to start using it in January of next year. See also http://xml.house.gov/ And it looks like the DTDs will be free to use and distribute!"

Comments

Stylesheet issues...

[jaaron]

It's because of the XSL style sheet they use. You can find it at http://xml.house.gov/Members/member-sorter-vb.xsl. (Use view source to see the actual XSLT). Notice that they use VBScript!

Re:Uhhh....

[MiTEG]

It's all screwed up with Opera 6.01 also.

They are using WordPerfect Too

[frank249]

It reports that the HR has made 100 DTDs and uses Microsoft Word and a special converter to do the job.

The article actualy says It shows how each line, name and term has an identifying tag, created by exporting the document from a word processor such as Microsoft Word or Corel WordPerfect into a special XML template.

That would make sense since most of the US government still uses WordPerfect. WordPerfect comes with extensive XML publishing functions including making your own DTDs.

BTW Corel just announced that a new version of Ventura Publisher is coming out in the fall with cross platform XML publishing built in. The next version of WordPerfect is also going to have a much better XML publisher now that they bought XMetaL.

It's the XSLT

[Anonymous Coward]

in the second line of the xml:
<?xml:stylesheet type="text/xsl" href="member-sorter-vb.xsl"?>
in the 6th line of the above-referenced xsl document being used to transform the xml:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" language="VBScript">

basically, they're using the MSXML parser to do their XSLT on the client-side. I've been working with this stuff for a while, and there are a lot of advantages to doing this. The MSXML parser is a lot more mature & well documented than whatever comes built into NS6 & Mozilla(if you know better, please point me to some good resources for working with client-side XSLT on these browsers-- i've looked everywhere).

But it seems to me that public accessibility to to these documents should preclude this, and demand that the parsing be done on the server-side.

Beyond that, the fact that they're using VBScript instead of JavaScript for their scripting is indicative of the fact that the people in charge of this initiative are hardcore MS-Heads -- ther's no reason for it, you can do some extremely complex stuff with the MSXML parser and JavaScript.

I know this is paranoid, but my past experience has been that even people inside MS use JScript if they can avoid VBScript... unless they're forced to use it for marketing reasons. Wonder who's in charge of this initiative.

DTDs, Schema, and XDR

[jaaron]

Actually, if you check the source, you'll see that they are using XML namespaces and schemas. Actually, they're using something called XDR (XML-Data-Reduced) which was developed by Microsoft and is upwards compatable with XML schema. I'm familiar with schema but not XDR. For more information, you may want to check out these links:

• http://www.schemavalid.com/faq/xml-schema.html#a4
• http://www.netcrucible.com/xslt/msxml-faq.htm#Q13
• http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm
• http://www.w3.org/TR/1998/NOTE-XML-data/

And thanks to this poster for pointing it out.

Indeed, it's not free

[twitter]

The mention of M$ Word put me on alert, as have previous stories here which have demostrated that XML will simply be a container for propriatory data formats like M$ Word. Closer examination, however, reveals a much more horrible arangement.

XML is dependent on unicode, as the US Government site's reference states. Follow the W3C to unicode ,

Unicode is required by modern standards such as XML, Java, ECMAScript (JavaScript), LDAP, CORBA 3.0, WML, etc., and is the official way to implement ISO/IEC 10646.

Unicode is owned by Unicode Incorporated and all of it's documents and standarts are issued under a restrictive license with a unilaeral change clause:

Modification by Unicode Unicode shall have the right to modify this Agreement at any time by posting it to this site. The user may not assign any part of this Agreement without Unicodes prior written consent.

Dare I compare this evil arangement to ASCII and other predecesors? To have IBM, M$, Sun and other OWN the very format your data takes and to be able to change it and break previous implimentations at whim, and YOU may not? Who wants to be a plump nickle that any thing vaugly resembling unicode in the future will be called a "derivative" and it's distribution halted? Is this not a collusion of comercial software vendors to control information at it's most basic representation? Does anyone else here see this as the ultimate extention of copyright? Evil, Evil, Evil.

I'd rather see the US government continue to publish in the American Standard for Information Interchange. This extensible standard is no standard at all.

Re:Uhhh....

[perlfool]

The main reason it doesn't render in Mozilla is they used an old XSLT Working draft namespace "http://www.w3.org/TR/WD-xsl". The XLST 1.0 namespace should be: "http://www.w3.org/1999/XSL/Transform"

See Unofficial MSXML XSLT FAQ" for some info about the old Working Draft, XSLT 1.0 and Internet Explorer.

Re:Was there any doubt they wouldn't be free?

[feronti]

Um, did you read the source? Or did you just open it up in IE? Because the source is clean (though not prettily formatted:), pure, 100% XML. In fact, there's only one namespace declaration in the entire thing (XLink, which they use to embed hyperlinks between various parts of the documents). All in all, this is some of the cleanest XML I've ever seen (including XML I've written myself by hand:)

But if you opened it up in IE, IE applies a stylesheet to all xml documents which gives you a nice collapsible view of the document tree (which is often easier to read than the source:)