I didn't say that I prefered the attribute (that was AiAustria), but at the time it didn't matter too much which type was used. Now it does, since I can use the exact same code to analyze both types of output if all the relevant XML nodes have the same name.

It's not a total showstopper, but unless there is a very good reason to keep things as they are, I would really prefer to have the element names the same as in the Profiler XML output.

Excellent! Thank you! 

Quoting GSyren:

Quote:
I just realized that there is a serious flaw in my XPath approach. XPath searches are case sensitive. Is there any chance that you can provide the variants in the correct case? If not, I'll have to scrap XPath and do it another way.

It would be disappointing, because XPath seemed so elegant. But consistent terminology between the two formats would still be very helpful.

Gunnar on this one, I have to respectfully decline. Every time I open and make changes, it results in extended time to stabilize it. And I would never depend on a case-dependent search. That spells doom.

Here is what I can do:

- pass what the user types in, through to the XML. That's where I get the variants from. The user decides the case.
- preserve the case from any exported Invelos XML. I think I am doing that. It is my intention, so I will check to make sure.

To go further, I would have to know apriori what variant case is "correct". I haven't studied it, so I always assume that any database that accepts user data has the potential to reflect whatever the user types in, so I don't know whether the names stored in credits are standardized.

Just FYI, I will share what I do, without making any recommendations, and I am open to improvements:

(1) Load a copy of the XML for searching, using "ToLower()" and squeeze out the printer control that is often in Invelos overviews that causes XML to crash.

xml = ("" + searched.GetXML(false)).ToLower().Replace("\f", "");

(2) For searching, I use "ToLower()" on the variants, and here is one of my Xpath statements that includes handling multiple embedded spaces.

castcredassearch = @"dvd/actors/actor['" + actorname + "'=normalize-space(@creditedAs)]";
crewFMLsearch = @"dvd/credits/credit['" + actorname + "'=concat(normalize-space(@firstname),' ',normalize-space(@middlename),' ',normalize-space(@lastname))]";


Then for the exported XML, I use the original XML instead of the copy I use for searching (I will double check to make sure).

In my testing, I have wanted to use another "normalize-space()" call surrounding the concatenation, but that doesn't seem to work.

Quoting mediadogg:

Quote:
Gunnar on this one, I have to respectfully decline.

Yeah, I kind of expected that. I thought I'd throw the qustion out there just in case you had an easy solution.

Quote:
It is "lower-case()" in Xpath 2.0 and beyond.

I don't find any mention of this in the Microsoft's documentation.
Is Xpath 2.0 included by default or is it something I need to download?

Never mind the Xpath 2.0. I tested converting the whole input file to lower case, and it wasn't as time consuming as I feard. I thought it might screw up something, but it seems to work.

Thanks!

I just noticed a couple of discrepancies in terminology between the formats.
For crew you have "Role" where Profiler XML has "CreditSubtype".
You have "ReleaseDate" where Profiler XML has "Released".
Can this be changed? I can program around it, but I think it would be best if the terminology is consistent.

Could I ask that we focus, as you once suggested, on the Invelos output of CLTBoss. I just have too many changes pending and my main objective is getting an accurate match to the CLT. If that means that you make a decision to not support the CLTBoss alternate format, I understand. I just can't keep track of all these changes and the ripple effects at the moment. Doesn;t mean I disagree, it is a management and focus issue.

Ok, I just felt that compatability between the formats would be a good thing. But no problem, I'll handle it.