Eeye: Wozu braucht man das targetNamespace-Attribut?

Hallo Forum

Nach längerer Abstinenz nun auch mal wieder ne Frage von mir:

Kurzer XML-sample Ausschnitt:

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="SQref"
  targetNamespace="http://www.SQref.com/def/SQrefInterface"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:tns="http://www.SQref.com/def/SQrefInterface"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">

[...bla bla bla...n'haufen tags und attribute]

</definitions>

Hier werden also im root-element <definitions> mehrere namespaces deklariert (xmlns = default-namespace und 3 weitere).
So weit so klar. Aber was zum Geier bringt mir das targetNamespace-attribut?
Und steht das tns-prefix nicht auch für TargetNameSpace? Ist das also einfach doppeltgemoppelt?

Bin etwas ratlos und nach stundemlangem w3c-drafts und rfc's wälzen leicht am durchdrehen %-)
Vermutlich hab ich's einfach irgendwo übersehen...

Bin dankbar für alle Antworten (vielleicht kennt ja jemand nen link zum w3c wo das definiert wird?).

Gruss und schönes Weekend, Eeye

  1. Hallo Eeye,

    Kurzer XML-sample Ausschnitt:

    <?xml version="1.0" encoding="UTF-8"?>
    <definitions name="SQref"
      targetNamespace="http://www.SQref.com/def/SQrefInterface"
      xmlns="http://schemas.xmlsoap.org/wsdl/"
      xmlns:tns="http://www.SQref.com/def/SQrefInterface"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">

    [...bla bla bla...n'haufen tags und attribute]

    </definitions>

    targetNamespace heißt "Zielnamensraum". Ein Zielnamensraum wird in XML-Schema dazu genutzt, festzulegen zu welchem Namensraum die Elemente gehören, die Du in Deinem XML-Schema deklarierst. Es gibt dann Mechanismen, um Elemente aus diesem Raum auszuschließen oder dazu zu fügen. Sowas geht mit DTDs übrigens nicht.

    Dein XML-Dokument ist ein WSDL-Dokument. WSDL ist eine XML-Anwendung zur Beschreibung von Web-Services (Web Services Description Language). Grob gesagt kannst du eine solche standardisierte Beschreibung in einer Art Repository ablegen, dann wissen andere Services, wie Sie diesen Service aufrufen müssen.

    XML-Schema wird in diesem Zusammenhang dazu genutzt, um z.B. Datentypen der Parameter festzulegen, die Methoden des Service erwarten. SOAP (s. soap-Namensraum) wird u.a. genutzt, um die Methodenaufrufe über HTTP-Requests zu ermöglichen.

    Naja, ob Dir das nun das ist, was du hören wolltest...

    Jedenfalls target-Namespace gehört zu XML-Schema:
    http://www.w3.org/TR/xmlschema-1/#composition

    und die Spec für WSDL:
    http://www.w3.org/TR/wsdl.

    Gruß
    Franz

    1. Hi, fjh

      *g* Ich arbeite grad an einem WebService Projekt, von daher hast du mir nicht wirklich was neues erzählt *gg*
      Trotzdem Danke für Deine Antwort.
      Ich hab schon ewig in den Specs rumgesucht, aber auf die Idee bei XML-Schema zu kucken kam ich bisher nicht. Danke für den Link.

      Also targetNamespace gehört zu XML-Schema und dient dazu den Namespace für die Elemente eines Schemas festzulegen. So weit so klar.
      Was hat aber targetNamespace in meinem XML- (korrekt erkannt, eigentlich: WSDL-)Dokument zu suchen? Weil den default Namespace für das Dokument leg ich meines Wissens nach mit xmlns="URI" fest. Und wie gesagt, den Namespace von dem Webservice leg ich nach Standart mit xmlns:tns="URI" fest, wobei tns auch targetNamespace heisst, soweit ich weiss. *grübel*
      Nun ja, das Dokument wurde automatisch erzeugt, und tut meinen Zweck. Sonst ist mir auch alles klar, ich hab mich über den Sinn und Zweck vom targetNamespace gewundert.

      Vielleicht noch irgendeine Idee?

      Gruss, Eeye

      1. Hi, fjh

        *g* Ich arbeite grad an einem WebService Projekt, von daher hast du mir nicht wirklich was neues erzählt *gg*

        Hm, interessant. Worum gehts denn. Erzähl doch mal ein wenig, wenn Du Lust hast und darfst.

        Was hat aber targetNamespace in meinem XML- (korrekt erkannt, eigentlich: WSDL-)Dokument zu suchen? Weil den default Namespace für das Dokument leg ich meines Wissens nach mit xmlns="URI" fest. Und wie gesagt, den Namespace von dem Webservice leg ich nach Standart mit xmlns:tns="URI" fest, wobei tns auch targetNamespace heisst, soweit ich weiss. *grübel*

        WSDL nutzt XML-Schema zur Beschreibung der *Struktur* eines Web Services, d.h. in einer WSDL-Datei gibt es eine Sektion

        <types>
        ...
        </types>

        in der das Schema einer Message (SOAP, HTTP oder was auch immer für ein Protokoll-Binding für den Web-Service verwendet wird) definiert wird.

        Z.B.

        <types>
          <schema targetNamespace="http://meinNamensraum/schema.xsd">
            <element name="Methodenaufruf">
              <complexType>
                ...
              </complexType>
            </element>
          </schema>
        </types>

        Definiert würde hier ein Element namens "Methodenaufruf", Dieses Element wird über targetNamespace dem Namensraum "http://meinNamensraum/schema.xsd" zugeordnet.

        Nutzt du dieses Element nun z.B. in einem <message>-Tag Deiner WSDL-Datei, dann muss es dort ein Namensraumpräfix erhalten, das den targetNamespace vertritt:

        <message name="RufeMethodeAuf">
          <part name="body" element="schema1:Methodenaufruf">
        </message>

        Und in deinem <definitions>-Element steht dann die Deklaration dieses Namensraums

        <definitions .....
                xmlns:schema1="http://meinNamensraum/schema.xsd">

        Es ist also beim targetNamespace was anderes als mit der Namensraumdeklaration. Über targetNamespace gibst Du den Namensrauman, zu dem alle deklarierten Elemente des Schemas bzw. auch der WSDL-Datei gehören. Mit der Namensraumdeklaration ordnest du ein Präfix diesem Namensraum zu, was Du dann benutzt, um die Elemente als aus einem Namensraum stammend zu bezeichnen.

        Gruß
        Franz

        1. Hallo Hallo und guten Abend. Naja, so langsam geht's ja schon wieder richtung Morgen :-)

          Ahja. *Erleuchtung* So langsam wird mir die Sache klar. Es geht also um den Namensraum der Elemente die im WSDL-Dokument definiert werden. zB eben die Elemente einer Message. Das macht Sinn :)
          Tausend Dank! Dann kann ich ja nachher beruhigt schlafen *g*

          Also das ist eigentlich keine grosse Sache an der ich da arbeite. Ich bin z.Zt. bei IBM und die haben ja so nette Produkte wie den Websphere Application Server, den IBM HTTP Server (eigentlich ja Apache :) und natürlich die DB2 UDB. Dazu noch den WebSphere Studio Apllication Developer, dem Nachfolger vom VisualAge for Java. Ein ziemlich geiles Development Tool für WebApplications und eben auch WebServices. Im Bereich WebServices war IBM ja auch schon immer dabei. Zum Beispiel bei den SOAP Spezifizierungen und auch bei WSDL, wenn mich nicht alles täuscht. Um die Sache abzurunden hat IBM auch noch nen UDDI Server laufen (weiss aber nicht, ob der öffentlich zugänglich ist). Und da bei WebSphere die Version 4.02 kommt (oder schon releast ist? Keine Ahnung.), bei DB2 auch die Version 6 ansteht, diesen Sommer, und der Application Developer ja quasi ganz neu ist (mittlerweile final), bin ich jetzt seit ner Weile dabei, so 'ne Art Evaluierung zu machen und die neuen Tools mit den aktuellen Produktversionen zu testen, und deren Zusammenspiel, eben mit WebServices.
          Und meine WSDL Datei wurde eben von 'nem Wizard im Application Developer produziert. Desshalb hab ich mir die mal genauer angekuckt.

          So. Ich werd denn jetzt mal ins Bett gehen *gähn*

          Gruss und ein schönes Wochenende noch, Eeye

          1. hallo,

            Also das ist eigentlich keine grosse Sache an der ich da arbeite. Ich bin z.Zt. bei IBM und die haben ja so nette Produkte wie den Websphere Application Server,

            ja, und er will bis zum biegen und brechen nicht zulassen, dass man cocoon als servlet bei ihm einbindet.

            grüße
            thomas

            1. Hallo Thomas

              ja, und er will bis zum biegen und brechen nicht zulassen, dass man cocoon als servlet bei ihm einbindet.

              *g* Kommt mir irgendwie bekannt vor. Also nicht persönlich (hatte bisher nix mit cocoon zu tun), aber ein Freund von mir hat grad seine Diplomarbeit zu dem Thema geschrieben, und war auch mal ne ganze Weile am Fluchen.  < itpc75.fht-esslingen.de/da> Ist zwar nicht die komplette Arbeit, sondern eher deren praktische Umsetzung, aber vielleicht hilft Dir das ja irgendwie.

              Gruss, Eeye