SOFTware is HARD

For those who are attempting to write web services in .NET to be consumed in Java. The following are things to note or watch out for: Note the WS-I guideline found here Run the WS-I tests first to ensure that the web services comply with Basic Profile 1.0. Download the "Interoperability Testing Tools 1.1" from here Refrain from having the same name for operation and parameter type (this causes Axis 1.4 to fail as it attempts to generate classes for service and parameter type. Axis will try to generate the same class for both. For example: a complex type named search will "clash" with an operation with the same name. In the WSDL: <s:complexType name="search"> will "clash" with <s:operation name="search"> ) Refrain from incorporating non-ASCII characters directly into the content of a string property (which finally gets serialized into XML). Use character encoding instead. E.g., do not use “smart quotes” directly; us...

Software technical documentation is an expected deliverable for software systems. The expected audience will typically be the customer's IT or MIS department who may end up maintaining or even hosting the software system. The technical documentation may be written in the following format: verbose description using natural language pictorial representation using modelling language The level of detail may be: business level (for end-user) implementation level (for developer) The following diagram depicts the above: Examples of each are as follows (clock-wise order): Descriptive - Business Level documentation: use cases, process flow description Pictorial - Business Level documentation: screen flow, process flow diagram Pictorial - Implementation Level documentation: interaction & class diagrams depicting implementation classes Descriptive - Implementation Level documentation: code, data dictionary Given that there are many ways to view the software system (logical, physical, etc)...

This started off as a problem with writing a single XSL for RSS and ATOM feeds. To be fair, producing separate XSL files for RSS and ATOM feeds should not be a huge problem. Attempting to merge them is probably not trivial. Thankfully, writing a XSL file for RSS is pretty trivial. It uses regular XSL know-how. However, writing one for ATOM seemed very different! The reason is that the ATOM XML comes with namespaces. I've encountered these two namespaces in use in different feeds: <feed version="0.3" xmlns="http://purl.org/atom/ns#"> and <feed xmlns="http://www.w3.org/2005/Atom"> As such, a regular template match will not match the content of the document. <xsl:template match="feed"> I'll need to write the XSL such that both gets matched. In order to match the first feed, I'll need the template to be: <xsl:template match="{http://purl.org/atom/ns#}feed"> To shortcut this, you'll need to have a pref...

Admittedly, I don't really know much about Sharepoint Services (WSS): My experience has been mainly in the area of ASP.NET. All I really wanted to do was to write user controls for deployment in a Sharepoint site. However, setting up the development environment was a real torture! My setup is to be: Windows 2003 Std. Ed. SQL 2000 WSS 2.0 SP2 ASP.NET 2.0 SonOfSmartPart (to run user controls as webparts [ http://www.smartpart.info ]) For the most part, the installation of the operating system, database server and Sharepoint Services was a breeze. Hell began with ASP.NET 2.0... Upgrading the Sharepoint website to use ASP.NET 2.0 causes all the webparts to show "Web Part Error"! After ploughing through several posts, this was resolved by changing the trust level of the website. Web.config: <trust level="Full" originurl=""/> (Note that this is probably not appropriate for a "live" site; but heck, I'm only setting up a development site......