Comments on: SOA-Reliability (SOA-Rity) for HTTP http://www.goland.org/soareliability/ Technology, Politics, Food, Finance, etc. Mon, 23 Jan 2012 17:37:17 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Julian Reschke http://www.goland.org/soareliability/comment-page-1/#comment-5962 Julian Reschke Thu, 10 Nov 2005 19:35:26 +0000 #comment-5962 Hi Yaron, generating proper HTML lists from rfc2629 source is definitively non-trivial. I'll have a look at what exactly xml2rfc does in presence/absence of the compact attribute and see what I can do. Best regards, Julian Hi Yaron,

generating proper HTML lists from rfc2629 source is definitively non-trivial. I’ll have a look at what exactly xml2rfc does in presence/absence of the compact attribute and see what I can do.

Best regards, Julian

]]> By: Administrator http://www.goland.org/soareliability/comment-page-1/#comment-5961 Administrator Thu, 10 Nov 2005 18:15:28 +0000 #comment-5961 XML2RFC though does a great job because it still supports the compact attribute. What I'm looking for is to get equivalent support in your XSLT script for generating HTML. Is there anyway to do that with your XSLT? XML2RFC though does a great job because it still supports the compact attribute. What I’m looking for is to get equivalent support in your XSLT script for generating HTML. Is there anyway to do that with your XSLT?

]]> By: Bernd Eckenfels http://www.goland.org/soareliability/comment-page-1/#comment-5959 Bernd Eckenfels Thu, 10 Nov 2005 07:47:27 +0000 #comment-5959 With docbook i know one has to use simplepara instead of para in unnumbered lists to make them render without empty lines, dont know about xml2rfc With docbook i know one has to use simplepara instead of para in unnumbered lists to make them render without empty lines, dont know about xml2rfc

]]> By: Administrator http://www.goland.org/soareliability/comment-page-1/#comment-5948 Administrator Wed, 09 Nov 2005 22:32:46 +0000 #comment-5948 Julian, #1 - D'Oh!!! I didn't even realize I could put the section in back. I changed appendix to 'section', put it into the back element and voila, beautiful output. #2 - The whitespace is my fault. Sorry. BTW, the 'length' check on artwork is VERY nice! I just wish it could include a standard message that says "max length = 78 characters" (or whatever it is). #3 - Yes, I exactly want what the compact attribute did. Compare the IANA Considerations section of the HTML draft to the Text draft (both linked at the top of this page). The HTML draft is nearly unreadable while the text draft is clear. But in any case thank you for your XSLT! Julian,
#1 – D’Oh!!! I didn’t even realize I could put the section in back. I changed appendix to ‘section’, put it into the back element and voila, beautiful output.
#2 – The whitespace is my fault. Sorry. BTW, the ‘length’ check on artwork is VERY nice! I just wish it could include a standard message that says “max length = 78 characters” (or whatever it is).
#3 – Yes, I exactly want what the compact attribute did. Compare the IANA Considerations section of the HTML draft to the Text draft (both linked at the top of this page). The HTML draft is nearly unreadable while the text draft is clear.

But in any case thank you for your XSLT!

]]> By: Julian Reschke http://www.goland.org/soareliability/comment-page-1/#comment-5877 Julian Reschke Wed, 09 Nov 2005 00:59:28 +0000 #comment-5877 Yaron, thanks. #1 - "appendix" currently is sort-of deprecated in xml2rfc (I think the DTD doesn't even allow it) -- just use "section" elements in the "back" section and everything should be fine. #2 - I currently don't see a problem with whitespace in artwork, but maybe this is because you worked around it already; please send details and I'll try to enhance the XSLT. Rendering lists is indeed problematic. Are you looking for something similar to what the deprecated "compact" attribute on HTML lists does? Best regards, Julian Yaron,

thanks.

#1 – “appendix” currently is sort-of deprecated in xml2rfc (I think the DTD doesn’t even allow it) — just use “section” elements in the “back” section and everything should be fine.
#2 – I currently don’t see a problem with whitespace in artwork, but maybe this is because you worked around it already; please send details and I’ll try to enhance the XSLT.

Rendering lists is indeed problematic. Are you looking for something similar to what the deprecated “compact” attribute on HTML lists does?

Best regards, Julian

]]> By: Administrator http://www.goland.org/soareliability/comment-page-1/#comment-5744 Administrator Sat, 05 Nov 2005 19:44:19 +0000 #comment-5744 Julian, yeah, using an empty organization element would have worked perfectly. But it meant a ton of extra typing for me. I would have to turn the 26 author elements in the bibliography from a simple element with attributes to an element with an empty child. It was just too much typing! I used your XSLT transform and it is much prettier than XMLToRFC's HTML transform. But it does have two problems: #1 - The appendix entries don't show up in the TOC #2 - The artwork examples all seem to add in an extra space on the first line. I also wish that the transform would render lists more tightly (XML2RFC has the same problem). All that white space and extra lines makes the IANA Considerations section difficult to read. But these are nits. It's great work and I'm changing the HTML file on the website to use your example. Julian, yeah, using an empty organization element would have worked perfectly. But it meant a ton of extra typing for me. I would have to turn the 26 author elements in the bibliography from a simple element with attributes to an element with an empty child. It was just too much typing!

I used your XSLT transform and it is much prettier than XMLToRFC’s HTML transform. But it does have two problems:
#1 – The appendix entries don’t show up in the TOC
#2 – The artwork examples all seem to add in an extra space on the first line.
I also wish that the transform would render lists more tightly (XML2RFC has the same problem). All that white space and extra lines makes the IANA Considerations section difficult to read.

But these are nits. It’s great work and I’m changing the HTML file on the website to use your example.

]]> By: Julian Reschke http://www.goland.org/soareliability/comment-page-1/#comment-5737 Julian Reschke Sat, 05 Nov 2005 08:05:00 +0000 #comment-5737 Re: xml2rfc I think specifying an empty organization element will make xml2rfc do what you want. (you may also want to try http://greenbytes.de/tech/webdav/rfc2629xslt.zip for generating HTML) Best regards, Julian Re: xml2rfc

I think specifying an empty organization element will make xml2rfc do what you want.

(you may also want to try http://greenbytes.de/tech/webdav/rfc2629xslt.zip for generating HTML)

Best regards, Julian

]]> By: assaf http://www.goland.org/soareliability/comment-page-1/#comment-5700 assaf Mon, 31 Oct 2005 18:56:20 +0000 #comment-5700 On second thought, I think you're right and this doesn't belong in the protocol. I do have a use case where the sender has a known recovery window, and doesn't want to talk to the receiver unless the time window is at least as long. But I can solve that at the URL level, without adding another layer of complexity to the protocol. On second thought, I think you’re right and this doesn’t belong in the protocol.

I do have a use case where the sender has a known recovery window, and doesn’t want to talk to the receiver unless the time window is at least as long. But I can solve that at the URL level, without adding another layer of complexity to the protocol.

]]> By: Administrator http://www.goland.org/soareliability/comment-page-1/#comment-5680 Administrator Sat, 29 Oct 2005 22:47:25 +0000 #comment-5680 Yeah, I looked at the ATOM issue and just adding a message ID won't do it. This is actually the second reliable messaging system i've designed so I've been through this before. The FI header (or equivalent) really is an important aspect. Is there anyone in the ATOM world I should work with on discussing the issues and how SOARity can be submitted as a way to solve their problem? Yeah, I looked at the ATOM issue and just adding a message ID won’t do it. This is actually the second reliable messaging system i’ve designed so I’ve been through this before. The FI header (or equivalent) really is an important aspect. Is there anyone in the ATOM world I should work with on discussing the issues and how SOARity can be submitted as a way to solve their problem?

]]> By: Barnaby James http://www.goland.org/soareliability/comment-page-1/#comment-5679 Barnaby James Sat, 29 Oct 2005 20:36:12 +0000 #comment-5679 You should definitely consider submitting this to IETF. The IETF ATOM Publishing Protocol is trying to do something similar (see <a href="http://www.intertwingly.net/wiki/pie/PaceGenericTitleAndId" rel="nofollow">http://www.intertwingly.net/wiki/pie/PaceGenericTitleAndId</a>) although your analysis of the problems seems more developed. You should definitely consider submitting this to IETF. The IETF ATOM Publishing Protocol is trying to do something similar (see http://www.intertwingly.net/wiki/pie/PaceGenericTitleAndId) although your analysis of the problems seems more developed.

]]>