Namespace prefix - InfoPath Dev
in

InfoPath Dev

Use our Google Custom Search for best site search results.

Namespace prefix

Last post 12-24-2004 12:39 AM by jonbrave. 2 replies.
Page 1 of 1 (3 items)
Sort Posts: Previous Next
  • 12-17-2004 09:11 AM

    • jonbrave
    • Top 200 Contributor
    • Joined on 10-15-2004
    • United Kingdom
    • Posts 59

    Namespace prefix

    Greg, I need some help, please, please :)

    It's about "namespace prefixes", and web services. I know web services are not your forte, but bear with me....

    My IP solution is "finished". It talks to a web service. All was working fine, till I tried it with .NET SP1. Here's the situation:

    The .NET framework generates the schema automatically, in response to you connecting to a WS at design time from IP. You don't have much/any control over it (what it generates). I tracked everything down to a subtle difference in SP1 as to what it produces. Prior to SP1, the start of the schema included:
    <definitions ... xmlns:s0="http://mynamespace/" ...>

    As of SP1, it now includes instead:
    <wsdl:definitions ... xmls:tns="http://mynamespace/" ...>

    So it defines tns namespace prefix instead of s0, though they both refer to my namespace. Then at SP1 all my WebMethods are defined as tns:... rather than s0:...

    Bizarrely, IP still seems to work at this point. IP at design-time expected methods etc. to come out in s0:, but seems to cope with them actually arriving in tns:.

    But then my users are expected to take my "template" .XSN files and reconnect them at their site (just by working thru Tools..., Data Connections...), prior to adding new fields. If they're on SP1 (or vice versa), take my word for it, they end up with a mixture of s0:s and tns:s (the worst area is to do with the binding of the parameters to the "submit" operation); they're not supposed to have to edit my script code, some of which has s0:s; my "documentation" tells them the paths they will see in IP are s0:... etc.

    I seem to be able to get it to "work", but I'm worried I don't understand, there may be rules/conditions/whatever still with s0:, you get the drift. If I compare what I end up with after this, it's definitely not the same (as it ought to be) if I redesign "from scratch" on the new SP1 system. In that case, I would end up with nothing but tns:s. So I feel I'm in a "bad" situation.

    What does all this add up to? What are the consequences? What do/can I do? Why do all IP examples seem to use s0:? Like I said, the problem is that whichever of s0: or tns: is chosen by the .NET framework as the "default" namespace prefix it's going to use, that's what it will place my WebMethods in. I don't seem able to influence this, from what I have seen so far --- should I be able to?

    I can provide more detail if needed...
  • 12-17-2004 10:36 AM In reply to

    Hmm. So this was a form that was upgraded from V1 to SP1, right? Well, once you have an SP1 form, no V1 InfoPath user can use it anymore... they need SP1.

    "IF" SP1 uses tns: as the namespace of choice when building from scratch, consider making a copy of your form, doing a global search and replace (at least for this one data connection in question) to make all s0: into tns:... then see if you continue to have issues or if all is fine.

    If all is fine, then just update your documentation.

    I really don't have an answer for why this is happening. But my gut feeling is that if InfoPath is trying to convert s0: to tns: for some reason, just help it along and get it over with. :o)

    Greg Collins [InfoPath MVP]
  • 12-24-2004 12:39 AM In reply to

    • jonbrave
    • Top 200 Contributor
    • Joined on 10-15-2004
    • United Kingdom
    • Posts 59
    Absolutely no InfoPath V1 --- don't know where you got that from. Have only ever used InfoPath SP1.

    I think you're getting you're SP1s mixed up --- I have been talking about .NET v1.1 vanilla and with (.NET) SP1. The s0/tns change over is in the schema generated by .NET for web services before versus after .NET SP1.

    FYI, what I am saying is:

    * I design IP forms as "templates" distributed to my customers
    * They are expected to reconnect the templates at their site for their system, and then start tailoring them
    * I do not know whether they will have .NET Framework with or without .NET SP1
    * Then I am claiming that, in practice, if they are using .NET SP1 while I designed without .NET SP1 (or vice versa) then IP goes haywire when they attempt to redesign the forms I have supplied (I am undecided as to how well they run with no redesign, but that's not my situation really anyway)

    And the reason for this? Is that if you redesign IP forms based on a webservice which used s0 namespace prefix at designtime when your .NET system now uses tns namespace prefix then, while people say it shouldn't matter, in practice IP has stored so many literal strings which include the prefix that it does matter.

    The difference between my situation and many others seems to be that I am not in control of my target environment; plus, my end-users will need to modify my supplied forms. InfoPath works better when, for example, you're designing for an in-house system on a known machine.

    I have had to give up on this, and say my customers must run .NET SP1 (which I have changed over to and redesigned my IP forms for) to work with my IP forms. I didn't want to have to require this, but it seems simplest.

    Thanks for all your help over the past month. Merry Christmas to you!
Page 1 of 1 (3 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.