Slashdot Mirror

There is no chance that this patent can stand. I make my tax euros exactly that way. I published first implementations of that mechanism around '93 (using SGML of course, there was no XML; LaTeX, Lout, roff and other scripts where mixed). I'm even doing this to implement distributed operating system. I'm using that to proof intrusion resistance, incorruptibility and non-deniability.

Some looser has wasted some $ for patent fees.

What ever happened to "Transaction Authority Markup Language (XAML)"?
It would appear that the xaml.org website is no longer online.

This stuff uses an open source OS, TinyOS which is written in and includes the language nesC, "an extension to the C programming language designed to embody the structuring concepts and execution model of TinyOS. TinyOS is an event-driven operating system designed for sensor network nodes that have very limited resources (e.g., 8K bytes of program memory, 512 bytes of RAM)."

Over the last couple of days I downloaded and installed TinyOS 1.1.0 for windows (146Mb!) which includes nesC, an emulator, a tutorial and cygwin. To my slight surprise it all auto-installed and worked perfectly and can even generate cute graphical self-documentation.

NesC is interesting for at least a couple of reasons - compile-time detection of race conditions, and bi-directional interfaces which specify both the commands which must be implemented by an interface "providers" (ie "servers") and the events (or callbacks) which must be implemented by the interface's "users" (ie "clients").

I'd say that bi-directional interfaces are a significent step in the evolution of object-oriented design, which are being echoed (at a higher level, and in a different technical culture) in the choreography languages of Web Services.

If you enjoy the challenge of learning a new language which is small, different, timely and purposeful, I'd recommend TinyOS and nesC.

There is no XML "standard" for Office documents.

KDE recently announced that KOffice would embrace the document formats of OpenOffice.org.

This means that a Windows user running OpenOffice.org could save a document, send it to a KOffice user on Linux, and expect it to open.

There is an effort to make a standard XML based office document format. Two office suites, so far, embrace it.

Article in InfoWorld

OASIS charter

XML for the masses

I've been using exclusively OO.o for a number of months. I recently installed MS Office 2003 b2 and took it for a run, and while tight and very modern, it's full of many crazy features and the XML is writes is hopelessly unreadable.

Unfortunately XML alone doesn't guarantee data interchangeability between programs. And XML Schema doesn't do it either. Knowing whether or not Tag1 can be in Tag2 doesn't tell you what Tag1 or Tag2 mean or if they correspond to a data structure that you need or can use. For that you need data modeling.

For data modeling in XML I've looked at a huge number of languages: RDF, Iso step 28, and XMI were my favorites (though in my opinion XMI first starts getting interesting with ver. 2.0 which isn't even finished yet). Each has a few advantages and disadvantages. And of course there are lot more than just these. But the problem is that these are all very young standards and APIs which would make them useful are not abundant.

So maybe the author's right that XML is not yet good enough, but I think a lot of progress is being made.

I'm not fond of Microsoft (indeed, some people consider me a 'basher'), but I don't think the majority of Slashdot's reaction has been rational in this case. For instance, some quick googling brought up the following comment by Tim Bray; he is one of the authors of XML, by the way. ;-)

From: MS Office 'Office 11' XML as Seen by Tim Bray

Justin Lipton wrote:

> Does anyone know or have ideas about what XML enabled Office 11 actually
> means?

I got an extended (hours-long) demo of Word & Excel & XDocs from JeanPa and a product manager whose name I don't have handy, two or three months ago, so things may have changed but here's what I saw:

Both Word & this new XDocs thing can edit arbitrary XML docs per the constraints of any old XSD schema. No DTD supprt. There are some of the usual XML editor goodies such as suggesting what elements can go here and picking attributes. They have pretty cool facilities for GUIfied schema customization. Neither of them can help much with mixed content, which has always separated the men from the boys in the *ML editing sweepstakes.

I'm not sure that either of them are really being positioned as general-purpose XML content creation facilities up against Arbortext & Altova & Corel. I'm not sure that market is big enough to interest MS anyhow. XDocs is (strictly my opinion) an attempt to build a desktop application constructor at a level that is a bit more declarative and open than VB, but richer & more interactive than a Web browser. I'm not really convinced yet - I think MS would agree there's still quite a bit of product management to do - but it does seem to be a pretty clever piece of software. I'm pretty sure it's safe to interpret the advent of XDocs as MSFT's declaration that they're not going to do anything with XForms.

What actually turns my crank is that you can save word docs as XML and they have their own "WordML" tag set that gets generated. I took a close look at this and it's pretty interesting. Very verbose - every word on the page gets its own markup. Suppose you have the word "foo" in bold with single-underline, the WordML looks something like:

<r>
<rps>
<rp class="bold" />
<rp class="underline" lines="1" />
</rps>foo</r>

When you get something like a Word table or floating text box the markup gets really severely dense and ugly, but I didn't see anything that seemed egregiously wrong, it's not pretending to do anything more than capture all the semantics that Word carries around inside, which are correspondingly severely dense and ugly. And HTML tables get pretty hideous too.

Why did I like this? I didn't see anything that I couldn't pick apart straightforwardly with Perl, and if someone asked me to write a script to pull all the paragraphs out of a Word doc that contain the word "foo" in bold, well you could do that. Which seems pretty important to me.

The idea is that you can have a Word document with all that formatting and then you can mix that up pretty freely with your own schema stuff, and have validation, then you can save it as Word (your markup plus Word's) or as pure XML (discards Word's markup, leaving just yours). The old Corel WPerfect SGML editor used to be able to do this too. [snip]

I think it would be interesting to take a look at an example WordML document. Unfortunately, I don't have - nor to I plan to get - the beta for Office 2003. Would anybody like to post an example document of what Word 2003 presents?

The aggregator of television guide content is in an interesting business... and problem. Yes, it is costly to get guide data, and they need to recoup their losses. Screen scraping free guide websites bypass the ads, which is, of course, how those websites pay for their work.

But there are so many potential uses for free guide content in an easily transformable format. Besides VCRs or PVRs that can find programs for you, what about websites dedicated to finding your favorite shows, or a simple PDA app that alerts you when it finds out that your favorite movie is due to air? So where is the data? Who would provide it?

Well, with a standard format (or this ) for such data, I believe the producers of that content (or, rather, the distributors... the networks themselves) could provide that data. It's obviously in their best interests for that data to be accurate, and as freely and widely available as possible. They want people to find their shows. Combine it with a simple automated lookup-table translation of network names to your local cable station numbers, and you're set. Of course, something like this could put guide aggregator businesses out-of-business, and I really doubt it will ever happen... But it probably should!

On the other hand, for those of you, like me, who have just woken up, a translation is provided below:

[translation]"We're gonna, um, do some security stuff, because, uh, security is cool, and uh, terrorism, is like, bad. We don't know what we're going to do yet, though. Or how. Or why. But, ummm......dude this is some good shit *sniiiiiiiifffffff*"[/translation]

Sorry for the sarcasm, but any press release that takes up three pages, and could be summarised into thirty words, deserves to be mocked shamlessly. Mod me down, it needed to be said!!

Agreed! HTML can be really tough, especially remembering all the closing tags and the esoterics of XHTML, however it can be mastered with some effort!

This guide was a pretty good start for me, and then I mastered the nuances of embedded tags. Don't even get me started about the complexity of CSS cascading! I've programmed axiographical embedded C++ designs (why is C++ mostly programmed by men? I think it's a very feminine language) that were far easier than HTML.

One of the toughtest things about programming for the web is cross platform: Those little differences between platforms that can eat hours of your time trying to figure out whether the platform implements the 3rd or 4th recommendation of the X-DOMVG standard.

Is for InDesign to accept an XML document. I've never used it, but it looks like InDesign does have the capability you need... At least that's what this page says.

I'm guessing you could write XML in a text editor and dump it into InDesign. The problem you describe (turn off all the bells and whistles and just give me the outlining) seems made for a markup language solution. Trying to separate content from presentation with Word will make you crazy.

Since it appears that InDesign can create an XML template for you, you could then fill in the content with a good text editor (like jEdit, BBEdit, Vi, or Emacs).

Of course, XML is anoother ball of worms, but I'd rather use a text editor and XML rather than struggle with all the 'features' of Micros0ft Word.

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

Due to public outcry, the W3C abandoned its RAND policies; you can read about it here. AFAIK, this applies to SVG as well.

So, no.

"If we rely on HTTP we will melt the Internet. We at least have to raise the level of abstraction, so that we have an industry-wide way to do long-running requests--I need a way to send a request to a server and not the get result for five days."

If I am reading his statement correctly, Box feels HTTP is not suitable for processes that take long period to get a response. Even if you remove HTTP layer from SOAP, you would still have a problem. Say some one decides to by pass HTTP, use raw sockets and establish persistent connections. This means a stateful application has to be built on top of SOAP. I'm just guessing, but if Box is saying RPC has to have sessions and be stateful, that isn't a full solution. If a process like "place a stock order for MSFT when the price is less than 50.00 buy," a stateful application may not be the best solution. It might take 1 day or 2 months for the price to drop below $50.00.

Microsoft is a supporter of XLang which tries to address the problem of stateful transactions. One of the problems of this approach that I can see is it is limited in scalability and timeout. Once you say all transactions need to be stateful, what is an acceptable timeout? Do all transaction require the same timeout period? What are the rules governming timeout, persistence, and garbage collection of invalid/expired states?

Why not use event based protocol with rules to provide a higher level of abstraction than XLang. The way XLang treats transaction is with case statements. On the surface that sounds fine, until you realize for every company you do business with, you will have to add cases to handle new situations, which rapidly makes the system harder to maintain. EBXml in my mind uses a better approach, which divides business and functional logic and suggests rules as a possible mechanism. HTTP isn't really the problem for long processes (as in weeks and months). A better solution is event based protocol, so using HTTP isn't a big deal. This doesn't mean there are cases where HTTP is really bad for transactions. Cases where response time is a huge factor in processing a transaction, a persistent connection would be more suitable. Things like day trading applications where response time affects the price, you would be better off using persistent connections for RPC. It would suck for a day trading application to loose a buy order because there was a sudden spike in requests and the system couldn't reconnect to send confirmation. Having a persistent connection in this case is the best solution, because response time has to be rapid.

The thing the article does not mention is that a number of rights languages have already undergone a rather thorough peer review within MPEG 21, which is looking to adopt an open solution. I heard from a friend who attends that all of the submissions had problems (e.g. ambiguity) except for XrML which was subsequently adopted as the starting place for MPEG (neither he nor I work for the companies backing XrML).

Real's original rights language, XCML, was rolled into ODRL. ODRL was one of the standards that lost out so maybe that partly explains the strange logic.

However, certain technologies have been standardized, mostly in cooperation with IETF, but there is also a ISO version of HTML, so HTML is a standard. ISO-HTML is even stricter than W3C's HTML 4.01 Strict.

Office XP Developer Center -- Smart Tags

Office XP Developer Center -- Smart Tags (Russian)

'Smart Tags uitdaging voor ontwikkelaars'

All About Smart Tags

XML Cover Pages -- Microsoft Announces Smart Tag Software Development Kit with XML Support

CNET -- Smart Tags and Clever Features

CNET -- Smart Tag SDK (for Office XP)

dammit, meant to hit preview, not submit :P
nevermind that incomplete sentence in the post previous and here's that link again:

Here's the link again:
http://xml.coverpages.org/xmlMusic.html