Pushing String

Cool! And this one’s even got I18N support…

(Thanks to Paul Bryan for the tip! If you’re curious, my old one is here.)

It’s that time again — we’re just a month away from the deadline for the ACM Workshop on Digital Identity Management call for papers.

The theme, as always for this series, is timely: “Services and Identity”. Might Pat et al. be interested in submitting something on accessing attribute services in SOAP and REST environments?

Clemens and Gerry comment on a remarkable event: Microsoft shipping sample code…in Java…using a runtime stack the likes of which you have never seen before in a Microsoft product. It’ll be four years this week since the historic Sun-Microsoft agreement, and this sort of collaboration and proven interop is something the teams in both companies can really be proud of.

Sean McGrath reminds us of this ancient work from 2002; I think you’ll find it still has relevance and even poignancy today. Go you at once and read of the whole thing.

Harold Carr and team have continued their track record of excellence on Project Metro (which you might remember under the informal name Tango), a web services stack with superior interop in mixed Java/.NET environments.

Harold has shared the results of the latest plugfest, which took place on the Microsoft campus last week. He observes:

Note: our shipping product, Metro 1.0 (built into GlassFish V2 UR1 and runs in other web containers—e.g., Tomcat), interoperates with .NET 3.0 based on mostly non-standard specifications. What we tested at this plugfest was our current development codebase that will interoperate with .NET 3.5 based on standard specifications.

As you’d expect, lots of painstaking work has to go into this sort of work — congrats to the team on their great progress.

By the way, there’s gold in them thar hills if you’re working with Metro; check out Harold’s mention of the cool $175,000 (USD) award you can win.

Lauren gives her take on our fiberrific outing (or would that be “fibriffic” spelled her way?). I guess I needn’t have been so coy about the identities of “my very experienced and talented knitting friends”, and as it happens, she and Yvonne are also my very knowledgeable and talented colleagues. Lauren has a great crafting blog; I hope Yvonne considers blogging her crafting adventures as well.

Lauren notes that the tech quotient of the actual event was low, but we suspected there were plenty of techie-types in attendance. As we went around the room doing introductions in my Charting class, I mentioned that I had designed some XML-related cross-stitch charts; one young woman piped up: “You mean like web services?” Yowza.

One more language note: I learned a great acronym from the Creative Crochet Lace book. It’s common to yield to temptation repeatedly and buy lots of yarn for what is called one’s “stash”. Eventually you run the risk of a terrible condition called SABLE: Stash Acquisition Beyond Life Expectancy. This is an addiction, folks — clearly we should be taking it much more seriously. Time to start a .org!

The original XML Recommendation is 10 years old today. Happy XML Day!

These anniversaries feel a little artificial to me; my first clear memory of the XML work was a teleconference Jon Bosak had arranged among the “SGML on the Web Editorial Review Board” members in June (?) 1996, so for me XML is eleven [FIX: erroneously had twelve before] and a half years old. Of course, that just makes me feel ancient, but having just received my very first solicitation from AARP a few days ago (may I just say: eek) I’m getting used to the feeling.

On that early call, I remember insisting that we write down design principles before we do anything else; this was a core part of the methodology I used for SGML DTD development and I felt the effort would end in tears without it. (I’m pretty sure I was right.)

Right now I find myself sitting on a mountaintop in rural Ontario with my old friend Murray Maloney, who was also there at the beginning — in fact, with Yuri Rubinsky he had already been advocating for SGML on the Web by the time Jon began putting together his nefarious plan. I’ve been lucky to make so many lifelong friends through my work on SGML and XML; for some of us, as Tim demonstrates today, the people are a big part of the story.

As something of a birthday present, today I’m publishing something SGML-flavored that I hope may still be of use, or at least morbid interest, to modern XML practitioners. You see, I cowrote a book in the just-prior-to-XML era with another of my lifelong friends, Jeanne El Andaloussi, about SGML, in SGML. In DocBook, as a matter of fact. That methodology I mentioned above, with design principles and stuff? That came from this book. Now that the book is out of print, she and I discussed the matter, and we agreed to publish it here. For the occasion Jeanne penned this note:

Now that XML has become a commodity and most National XML User Groups have stopped their activities, it is time for our ELM methodology to be freely accessible on the Internet. I just hope our readers will have as much pleasure in reading it as we had writing it over a decade ago.

You’ll have to be the judge of how well the content has stood the test of time, but I can tell you the markup did beautifully. With a huge dollop of help from Norm Walsh (both his DocBook stylesheets and his mad skillz), the SGML-to-XML-to-HTML processing pipeline was downright trivial.

Voilà! We present to you Developing SGML DTDs: From Text to Model to Markup.

p.s. It turns out the old joke is true. XML is good for reuse. It lets you reuse all your old SGML presentations. (rimshot)

XPointer seems to have made its way into the heart of the Service Modeling Language! The SML spec defines an smlxpath1() scheme and everything, and seems to do it in the spirit originally intended. Wow.

Oh no:

The iPhone recently fell victim to its first Trojan attack….

Security blog F-Secure warns users to be wary, however; speaking to the modding community, blogger Jarno writes “Hopefully this serves as a warning for those who have opened their iPhones using a security hole in the system and then installing unverified software without a second thought to what they are doing.”

He continues, “This time it was an 11-year-old kid playing with XML files who created the trojan. Next time it might be someone else with more skills and with specific target.” [emphasis mine]

W3C has a working draft out on cool URIs for the semantic web that looks at how to choose URIs for RDF descriptions of both information resources (web documents) and non-information resources (such as people). The paper suggests that URIs should unambiguously refer to only one resource at a time — for example, Alice’s web page and Alice herself are distinct and should be referred to with different URIs.

This lofty philosophical topic (the whole resource-identifier/resource/representation-of-a-resource distinction still gives me a headache) gets boiled down to a fairly ordinary recommendation to use tricks like http://www.example.com/about#alice — a URI reference with a fragment identifier of “alice” — to refer uniquely to Alice the person, and to use content negotiation to retrieve an RDF description of what that particular referent actually is.

What’s more interesting to me is how “cool URIs for non-information resources” intersects with identity. I’ve noticed that the RDF world talks about people on the web, but the reality is that people do web stuff with a layer of several digital identities in between. For instance, it’s likely that http://www.example.com/about#alice, in the context of the scenario introduced by the paper, refers to Alice in her role as an example.com employee, and that she has a whole other digital life beyond the confines of example.com.

Of course, the notion of a URI referring to a digital identity maps nicely to OpenIDs… An OpenID really has three potential “audiences”: (1) it’s a machine-resolvable endpoint that OpenID consumer sites can use get the OpenID’s owner authenticated; (2) it’s often “human-resolvable”, allowing arbitrary people to follow the link and see a “home page” for that identity (anyone can go see what’s at http://openid.sun.com/xmlgrrl, for example); and (3) the string itself becomes a well-known name for its owner and provides the ability to correlate her activities across the web.

If we accept that a URI will tend to encompass only a part (a persona or whatever) of a whole person, Cases #1-2 are copacetic with the mechanism of resolving a URI to get a (possibly RDF-encoded) representation of a resource and doing content negotiation at one level or another to accomplish description-switching. Case #3 isn’t covered by the paper, in the sense that the special circumstance of URIs-themselves-as-resources isn’t touched on — though I dimly recall that RDF does deal with this as a use case. I have a nagging feeling that a complete “cool semantic web URIs” solution does need to account for this.

As I was doing all this pondering, I came across Scott Kveton’s post today on URL’s are people too … and service end-points. Aha! Indeed they are (allowing for the rhetorical conflation of the resource identifier with the resource itself, which doesn’t give me a headache). That’s really what I meant by talking about the “user as web resource” metaphor back in August. Depending on the sophistication of the metadata and the various services we choose to provide at that endpoint, a URI can, over time, do a better and better job of representing a flesh-and-blood person online.