invalid QName when transforming a .net XSLTransform

I have a piece of XML that is structured similar to this:

<root>
     <score name="Exam 1"><value>76</value></score>
     <score name="Exam 2"><value>87</value</score>
</root>

and I would like to transform it to look like this:

<root>
     <Exam 1>76</Exam 1>
     <Exam 2>87</Exam 2>
</root>

Following this article I am using this stylesheet:

 <stylesheet>
  <xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
   <xsl:template match='@*|node()'>
    <xsl:copy>
     <xsl:apply-templates select='@*|node()'/>
    </xsl:copy>
   </xsl:template>
   <xsl:template match='score'>
    <xsl:element name='{@name}'>
     <xsl:apply-templates/>
    </xsl:element>
   </xsl:template>
  </xsl:stylesheet>
 </stylesheet>

However, when I transform it and load it into a document, I receive this error:

System.Xml.Xslt.XsltException: 'Exam 1' is an invalid QName

It seems that many of the google results show people with this error have passed an empty string somehow, the error is "" is an invalid QName, but that's not the case here.

What is the problem? Is there a better, alternative solution?

From stackoverflow

• You cannot have a space in an element name.

  pc1oad1etter : Yep, that was it.

differences between 2 JUnit Assert classes

Hi,

I've noticed that the JUnit framework contains 2 Assert classes (in different packages, obviously) and the methods on each appear to be very similar. Can anybody explain why this is?

The classes I'm referring to are: junit.framework.Assert and org.junit.Assert.

Cheers, Don

From stackoverflow

• I believe they are refactoring from junit.framework to org.junit and junit.framework.Assert is maintained for backwards compatibility.

• The old method (of Junit 3) was to mark the test-classes by extending junit.framework.TestCase. That inherited junit.framework.Assert itself and your test-class gained the ability to call the assert-methods this way.

  Since version 4 of junit the framework uses Annotations for marking tests. So you no longer need to extend TestCase. But that means, the assert-methods aren't available. But you can make a static import of the new Assert-class. That's why all the assert-methods in the new class are static methods. So you can import it this way:

  import static org.junit.Assert.*;
  

  After this static import, you can use this methods without prefix.

  At the redesign they also moved to the new package org.junit, that follows better the normal conventions for package-naming.

• JUnit 3.X: junit.framework.Assert JUnit 4.X: org.junit.Assert

  Prefer the newest one, especially when running JDK5 and higher with annotation support.

• I did a rough source code compare and there are no serious changes.

  Lot of comments were added in org.junit.Assert and some refactorings are done.

  The only change is the comparison with Arrays. There are some code clean ups, but there's (imho) no functional change.

• There is in fact a functional change: org.junit.Assert will complain if you use the two-argument assertEquals() with float or double, while junit.framework.Assert will silently autobox it.

Migrating from one DBMS to another

Does anyone have any experience migrating from one DBMS to another? If you have done this, why did you do it? Features? Cost? Corporate Directive?

At times, I've worked with DBAs who insisted that we not use features specific to a DBMS (for example, CLR Stored Procedures in SQL Server.) The DBAs point is, if we use these features, it will make it more difficult to switch to another DBMS if we have to. But so far, I've never been asked to switch.

From stackoverflow

• In my opinion its silly not to take advantage of all the features of the db your using. Changing DBMS regardless of how many features you use is going to be difficult. There are minute differences between the systems (like some record Date and some record date and time) that will cause a huge headache to change. There is no such thing of just switching to a new dbms.

  From a business perspective there is a lot of work to be done. Analysis on the new dbs to change to. Figuring out the impact of changing dbs on the new system. Having development change the existing systems, testing the changes etc. The list goes on and on. Making a switch like that on an enterprise system takes months if not years. The last place I worked had to change dbs, and it took us a solid 11 months to do it and about 2 million dollars for consultants, hardware, software, and employee salaries. It's a big deal. If someone is saying not to use features, because that "may" happen someday and it'll be easier to do, Most likely, that person is off their rocker. The extra amount of time and money it will take to convert those features is minuscule compared to everything else (most likely). IMO if it will save time and money now buy using those features, then that is the best course of action.

  We did it because the systems we had running on the old dbms were too big. There was too much data, and we needed something a lot more powerful. Plus, it wasn't supported anymore.

• Switched many times. Mostly because the "Involuntary Conversion" -- an old product is no longer supported or is no longer suitable.

  • DB2 to Oracle. Pre-UDB data was preserved and moved into Oracle.
  • MS-Access to Oracle. Continued using the Access front-end over Oracle tables.
  • Oracle to Oracle. 6 to 8, I think...

  "why did you do it?" Not features. Not cost. In all cases, something is broken.

  • Old product no longer works. Either an OS upgrade or something else has made the legacy product break.
  • Old product did not scale.

  Switching is rarely something you choose to do. It's forced on you when vendors go out of business (Ingres did this once) or stop supporting your version (Microsoft does this frequently).

  Then, of course, it's a crisis. Compounded by the technical complexity of trigger and stored procedure changes. If it was only the data, it wouldn't be much of a crisis. Dump to some standard form (CSV, for instance), reload, and you're up and running.

  More importantly, the more "stuff" (stored procedures, triggers, etc.) in the database, the more your application software becomes a confusing pile of hard-to-follow (and hard-to-maintain) kludges. There's nothing so frustrating as waiting weeks for someone to track down a stored procedure name. If it was VB code, everyone would have had access to it. But since it was in the database, it became -- paradoxically -- less visible. Code is code and should be kept away from data.

  See Where to put your code - Database vs. Application? for more on this topic.

• I've been involved in several projects to migrate data from one database to another. In every case, it was the data that was being migrated--not the RDMBS. If an application is working then there's not going to be any pressure to switch databases for the sake of switching. The impetus for the migration is usually because the old system's data is either out-of-date, incompatible, or both, and that affords an opportunity to switch the RDBMS as well.

  The most likely change is to consolidate the reference data (employees, customers, etc) into the existing master database (for consistency and ease-of-use) and then modify all the other tables so that the keys are pointing to the new reference data. This requires schema and corresponding code changes up and down the stack. It's a data migration--not a database migration. And more than likely you'll want to take advantage of the opportunity to add data, or standardize names, or (de)-normalize the tables, etc.

  The upshot is that these projects nearly always have an enormous impact on the data, the schema, and the code, and any work required to--say--translate T-SQL into PL-SQL will be a trivially small part of the project. So if you're paying for a nice RDBMS, use all of it. To do otherwise would be like not using the trunk or the glove compartment of your new car so that it'll be easier to switch cars when you buy a new one.

• I worked at a company for a number of years, whose product supported either Oracle or SQL Server. We maintained the model in Erwin, and generated schema scripts, triggers and Oracle Packages from it. The packages were used to make the Oracle triggers work similearly to SQL Server ones (with a logical 'inserted' and 'deleted' tables) We kept two sets of Stored Procedure Scripts.

  With that mess under my belt, I would suggest that you can migrate big projects, so long as you can succesfully make your data tier completely seperate from any logic code. If you can do that, then you can implement whatever database features will speed up the application in the data tier, without affecting your core app.

• One other point (in support of S.Lott). Depending on your development environment your developers may not have an easy time developing or even viewing stored procedures. Splitting your application code between two different sets of development tools and execution environments can get complicated, and it can make it harder to find skilled employees.

  I don't think that's an argument against stored procedures, but it's certainly something to consider when deciding where the code should reside for a given component of your applications.

Oracle: TNS-12532: TNS:invalid argument

Trying to establish a connection between my windows box (2003 server) and the oracle (11g) database.

I'm able to successfully ping the oracle host from the windows box. However tnsping command fails with the error tns-12532 error.

Any ideas to solve this issue?

From stackoverflow

• From the Oracle Error Messages documentation:

  ORA-12532: TNS:invalid argument

  Cause: An internal function received an invalid parameter.

  Action: Not normally visible to the user. For further details, turn on tracing and reexecute the operation. If error persists, contact Oracle Customer Support.

  Have you followed that path yet?

• Sorry for the obvious question, but have you confirmed that you can connect to the db from another pc?

Use AppleScript or other Mac OS method to get filename and path of open files

Is there any way to use AppleScript (or something else) to query currently running applications for the filename and path of the current file that they have open? I know some applications show the filename in the window title which is script accessible, but this isn't a solution as not all do, and hardly any show the path. I also know this is complex because not every application is document based.

Any suggestions on how to find the currently opened file/path in running Mac apps would be appreciated. Thank you!

From stackoverflow

• http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/lsof.8.html

Tree library for PHP using left & right ids

I'm looking for a library in PHP that can create a tree structure from a database (or array of values) with left and right ids. For the result when getting values I am only looking for an array so I can create any type of view. For adding and removing, it would be nice if the library did it all. Even if the library is within another library, I don't mind as I'll probably pull it out and integrate it with my own libraries.

Anyone know of anything?

I'm using PHP & MySQL, so it'd be helpful if it used atleast PHP. If it's a different database I can probably convert it, although maybe the same with PHP if it doesn't use too much language specific functionality.

From stackoverflow

• This approach is called "nested sets"

  http://stackoverflow.com/questions/272010/searching-for-the-best-php-nested-sets-class-pear-class-excluded#272248

  basically there is the NSTree library which doesn't seem to be maintained and there is a PEAR library. Probably there are others but that's just a summary of the other post.

• ezComponents Tree library has different backends (tie-ins), that you can choose between. The documentation is pretty good as well.

• I am in the midst of a project that uses tree structures for navigation and also selection of (what to) update. I must admit that (being self-taught) I wasn't that familiar with the left-right values approach and so opted for what I have just discovered via a very helpful article to be called The Adjacency List Model.

  Having thought about it, and now being somewhat more familiar, I still think I'd do the same. With TALM, coding PHP views & updates are easy as you're primarily concerned with the parent relationship of a node.

  Then for display you have jQuery Treeview, which I can't recommend highly enough, and for selections there's jquery-checktree which I'm still in the process of incorporating and so can't vouch for, but looks good.

Render < instead of < in ASP.NET

I'm writing a small page to show the employees in our company. I've written a query to pull the info from our database. Then I'm binding that to a GridView to do the dirty work. Here is the query.

"SELECT tblEmpID.empid AS [Empl ID], tblEmpID.posno AS [Pos #], [name] & ""<br />""  &   [jcn] & ""("" & [jcc] & "")"" AS [Name/Job], [orgno] & "" - "" & [depname] AS Department, tblEmpID.[status] AS Status " & _
        "FROM tblEmpID " & _
        "ORDER BY [orgno] & "" - "" & [depname], tblEmpID.name "

As you can see, I'm trying to include a
inside the SQL so when it renders it will look like:

Name
Job Description

But when it renders it renders as

< and >

Effectively showing the <br /> in the record instead of formatting it like I want.

So how to I make it render like I want? I've already tried escaping the < with \ and that did not work.

---

EDIT: Thanks gfrizzle. Your answer set me down the right path. Also, thank you NYSystemsAnalyst. Your answer helped me think of a different way to do things in the future. Ultimately, I found a different solution. I put this code in the GridView1_RowDataBound event and it does what I need.

If e.Row.RowType = DataControlRowType.DataRow Then
        Dim cells As TableCellCollection = e.Row.Cells

        For Each cell As TableCell In cells
            cell.Text = Server.HtmlDecode(cell.Text)
        Next
    End If

From stackoverflow

• If you are doing this for read-only purposes, you may want to consider using the repeater control. Then, you can return those as separate fields, thereby eliminating the HTML from the SQL result set. Then, you can use the ItemTemplate in the control to specify the HTML and exactly how you want the results to appear. You can place them in a table, and use the BR tag. This will look similar to a grid, but give you more control over the layout on the HTML / .aspx side.

• Try setting HtmlEncode="False" on the column in the GridView. That should stop it from encoding your markup.