News from WS-SX: WS-SecureConversation and WS-Trust are now OASIS Standards

On the 26. March I wrote an entry named WS-RX, WS-SX and WS-TX - what's the status? and now I've just discovered that the day after WS-SecureConversation and WS-Trust were announced as OASIS Standards. That's great news for the WS-* stack, but not big enough to make it to the front page of the WS-SX TC's home page :-).

Navbar styling

In an ealier post called Valid XHTML - the blogger navigation bar i looked at the navbar. The navbar is called as a seperate webpage with certain parameters one of which is navbarType that per default has the value BLUE with the new XML templates (I didn't use blogger before so I have no real knowledge of how it used to be. I seems obvious that this is a way to style the navbar, but it's not obvious what values are allowed and I haven't found a setting for it in the Customize section.

A search on Google for NavbarType blogger didn't give any obvious hits on the blogger help or discussion forums, but i did see some of the valid color themes like ex.:

• BLUE
• BLACK
• SILVER
• TAN

but not ex.:

• YELLOW
• WHITE

Almost valid XHTML with "Minima Stretch"

Finally I've collected energy to give the work for a template that produces valid XHTML a shot again. I'll use the post The Firefox is a Panda! as a test case because it's small and simple, so I can focus on the template.

To validate the page (template) I'll use the W3C Markup Validation Service and call it with a reference to the mentioned blog post.

I've fiddled with the templates before and once ruined some of the functionality (missing CSS-sheets) also when I realized that it was probably going to be impossible to get a complete valid blog my enthusiasm took a hit, but now I'll try to see how far I can come, and I'll try to keep track of what changes and the score as I implement all the changes. The order will be more or less random and then I'll maybe make a more systematic grouping and analysis in a later post and update the postings that I've all ready made.

To get started I first reset the template by choosing Revert widget templates to default in Template -> Edit HTML -> Revert widget templates to default, which wipes all the customizations that's been made to the widget part of the template, that's the <body> element tag in more practical terms, all the widgets that you've added stays but revert to default. Then I choose the template once more inn the Pick New Template sub menu under Template. When validating the page I got 117 errors which is actually much better that the first time with my former template.

The needed changes I've made are:

1. comment in the skin tag after CDATA section, and removed xtra -- to keep the comment section valid (83 errors).
2. Replacing navbar (74 errors).
3. Moved the namespace declarations to the first level custom element (71 errors).
4. Making Wellformed link for 'Email Post' (70 errors)
5. post body in div tag instead of p tag (69 errors)
6. well formed link to quickedit (68 errors)
7. Making the 'comments-block' dependent on real content of 'data:post.comments' (67 errors)
8. making the 'Post a Comment' link well formed (65 errors)
9. replacing target='_blank' with rel="external" (65 errors)
10. deleting 'quickedit' includes in sidebar (51 errors)
11. adding xtra 'amp;' to link templates in <b:includable id='toggle' var='interval'> (24 errors)

Extras:

1. Adding Google analytics
2. Adding inline favicon
3. Adding link to W3C Markup Validator

What remains are still the faulty Archive widget that gives me the 24 errors and to eliminate that I'll either have to wait for the blogger team to correct the error (close to a miracle) or do some heavy rewriting that I'll dodge for now :-). Also parts of the template isn't used with this post, ex. comments, so those parts probably also needs some taking care of later.

As for how browsers present the produced markup I've only used Firefox 2.0 where i looks correct and I've just tried Konqueror 3.5.6, which looks almost correct except for the uneeded vertical scrollbar for the navbar.

Wellformed link for 'Email Post'

My earlier post Valid XHTML - the layout tags gave an example of a layout tag that produces invalid xhtml (not wellformed XML). Another example is the Email Post, but contrary to the archive example the Email Post one can be worked around.

The following markup fragment shows what's produced by default:

<span class='item-action'>
  <a href='http://www2.blogger.com/email-post.g?blogID=591744930960839717&postID=1676954542643567733'    
     title='Email Post'>
    <span class='email-post-icon'> </span>
  <</a>
</span>

The problem is that the & should be &amp;. The corresponding template fragment looks like:

<!-- email post links -->
<b:if cond='data:post.emailPostUrl'>
  <span class='item-action'>
    <a expr:href='data:post.emailPostUrl'
       expr:title='data:top.emailPostMsg'>
      <span class='email-post-icon'> </span>
    </a>
  </span>
</b:if>

the problem comes from the expr:href='data:post.emailPostUrl' part, but that can be replaced (rewritten) with:

expr:href='"http://www2.blogger.com/email-post.g?blogID=59174493096083971&postID=" + data:post.id'

with a hardcoded blogid for my blog, but to make it work on any blog the blogid should be accessed by a data tag:

expr:href='"http://www2.blogger.com/email-post.g?blogID=" + data:blogid + "&postID=" + data:post.id'

or even smarter if the virutal hosting also evaluated the other functions, then it could have been some thing like (if using custom URL):

expr:href='data:homepageUrl + "/email-post.g?postID=" + data:post.id'

There's a related article in help section called How do I change the Email-This-Post icon? based on the classic template.

Transport, Transfer and Application - levels in Reliable Messaging

My first post on Reliable Messaging: What kind of reliability do I get with Web Services Reliable Exchange (WS-RX)? just scratched the surface and now it's time to get a little deeper into it.

In the current version of Web Services Reliable Messaging (WS-ReliableMessaging) (Committee Draft 04, August 11, 2006) the layering are explained in section 2 Reliable Messaging Model:

Figure 1 below illustrates the entities and events in a simple reliable exchange of messages. First, the Application Source Sends a message for reliable transfer. The Reliable Messaging Source accepts the message and Transmits it one or more times. After accepting the message, the RM Destination Acknowledges it. Finally, the RM Destination Delivers the message to the Application Destination. The exact roles the entities play and the complete meaning of the events will be defined throughout this specification.

Alright, so the message is not delivered to the application but to the RM Destination! I've found an interesting discussion from the xml-dist-app list that touches on this subject with the title Action Item - Part I: WSRX and MEP signaling on the wire. In a reply from Christopher B Ferris he writes:

I have long argued that if you need an application-level ack, then have the application send one. The purpose, as I see it, of the reliable messaging layer is to ensure a successful hand-off, not to ensure that the application does, or even can, process the message.

That was for seperating the application from the other layers, but it's not that simple since the non-application level can worked with as well (se this post):

> The reliability standards I've seen distinguish between submit/deliver and
> transmit/receive.

i.e. they distinguish between transfer and transport (respectively).

> The upshot here is that, even if I use a TCP-based transport, and even if
> that transport allows for status codes or some other indication of a
> successful exchange, successful transmission of a message does not imply
> successful delivery.

If it's a transfer protocol, that's *exactly* what it implies.

Sorry for my terseness, but I'm simultaneously bleeding from the ears,
pulling out my hair, and gritting my teeth, wondering why oh why folks
continue to treat application protocols like HTTP as transport
protocols, when what you clearly need *is* a transfer protocol!!

I'm not sure I get the fine details here, but I guess the meaning is that HTTP is transfer protocol for Hyper Text, which is used by the XHTML application called a browser (in line with the application/xhtml+xml media type instead of good ol' text/html). In another branch of this thread it ends in a architectural discussion between Mark Baker and David Hull:

> It's the *same* target, hence the suspicious similarity. Really.
> That's why I've been so vocal about this for the past 6 years!!
> Loosely coupled document exchange between distributed applications;
> that's what we're all after, right?
>
>
Only if you agree that messaging is essentially the same as loosely
coupled document exchange, which I don't. From my point of view,
document exchange is one useful segment of the design space. Messaging
is another. See my previous post for more detail.

Well I don't know who's right but from my current level of understanding I agree with Mark Baker, that is loosely coupled document exchange and adding a level upon it to ex. ensure in order doesn't change that for me.

Intermediaries

One aspect is the application stack another and very SOAP-ish is that of intermediaries (Actors) that I haven't had any use of yet, here also single out that aspect:

> As far as I can tell, there shouldn't be any significant difference > from the reliability layer's point of view between forwarding a > message along another hop and doing some other sort of processing > before declaring it delivered. In either case, I don't send back an > ack until something arbitrarily long-running and outside my control > finishes happening.

Respectfully, I disagree.