RE: question on XML namespace names
The URI in a namespace declaration is simply a name. It isn't required to point to anything, and you should never expect that the URI is resolvable. But quite often it does resolve -- typically to a metadata document, such as XSD, DTD, WSDL, etc. Anne -Original Message- From: Ken Gross [mailto:[EMAIL PROTECTED] Sent: Sunday, August 01, 2004 4:28 PM To: [EMAIL PROTECTED] Subject: question on XML namespace names Is anyone on this listserv using namespace names to retrieve W3C .xsd or .dtd documents? To be more specific, if you are using fully qualified names for XML namespaces as the standard seems to recommend, what kind of object lives at the specified address: (A) nothing (B) html documentatation (C) W3C .xsd or .dtd document (D) other (please specify) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Namespaces inherited?
Tim, In the first example: ns:elemA xmlns:ns=urn:myNS elemB/ !-- this elem would implicitly be in the 'ns' namespace -- /ns:elemA ElemB is either unqualified or it is qualified by the default namespace (the xmlns=some-uri declaration, if there is one). There's no assumption that it belongs to its parent's namespace. Namespace *declarations* are inherited. In other words, you don't have to redeclare your namespaces for each child element. So, for example: elemA !-- this elem is in the default namespace -- xmlns=urn:myNS xmlns:joe=urn:joeNS xmlns:fred=urn:fredNS elemB !-- this elem is in the default namespace -- joe:elemB/ !-- this elem is in the joe namespace -- fred:elemB/ !-- this elem is in the fred namespace -- /elemB /elemA If you couldn't inherit namespace declarations then you would need to do this: elemA xmlns=urn:myNS elemB xmlns=urn:myNS elemB xmlns=urn:joeNS/ elemB xmlns=urn:fredNS/ /elemB /elemA Anne -Original Message- From: Watts, Tim T [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 2:22 PM To: [EMAIL PROTECTED] Subject: Namespaces inherited? Hello, I read that child elements inherit the namespace of their parent by default (Professional Java SOAP, p30, Wrox Press). The W3C spec says that they're in scope for all children. But that's not the same as inheriting. To my understanding, inheriting would mean that the children automatically become members of the parent's namespace unless explicitly overridden while in scope means that the namespace is merely *available* to the children. According to the book, the following examples are semantically equivalent: ns:elemA xmlns:ns=urn:myNS elemB/ !-- this elem would implicitly be in the 'ns' namespace -- /ns:elemA ns:elemA xmlns:ns=urn:myNS ns:elemB/ /ns:elemA I don't think this is correct but I would like to hear from more knowledgable sources. The behavior of the Xerces implementation of DOM does not conform to the above. - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Removal
You also need to make sure that you unsubscribe using the same email address that you subscribed with. -Original Message- From: Martin Stricker [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 8:14 PM To: [EMAIL PROTECTED] Subject: Re: Removal Scott Dewitt wrote: All: I don't mean to be rude but I have sent several notes to unsubscribe to be removed from the list and even e-mailed the webmaster. Could someone please resolve this issue and remove me from the list? To unsubscribe, e-mail: [EMAIL PROTECTED] This doesn't work? You should get a confirmation e-mail, and upon replying to that you should be out. Or try list-help: mailto:[EMAIL PROTECTED], that should send you an e-mail with detailed instructions. Best regards, Martin Stricker -- Homepage: http://www.martin-stricker.de/ Linux Migration Project: http://www.linux-migration.org/ Red Hat Linux 7.3 for low memory: http://www.rule-project.org/ Registered Linux user #210635: http://counter.li.org/ - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] WASP Lite on Apache?
Dims, We moved the discussion to axis-dev. There's a fair amount of work that we'd need to do to clean up our code before we submit it to Apache, so before we do this work we want to ensure that our code will be useful to you. We talked about the possibilities of merging Axis and WASP, but considering the differences in architecture, merger appears to be very challenging. We've just released a new version of our C++ implementation, which we've also offered to submit to Apache. Both implementations are based on the same architecture. Our C++ implementation is already open source, so we've requested that the Axis team look at this code before we proceed further. We haven't heard much discussion since then. Regards, Anne -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 18, 2001 10:13 AM To: [EMAIL PROTECTED] Cc: Anne Thomas Manes Subject: Re: [POLL] WASP Lite on Apache? Anne, It's been over a month since we heard from you on WASP-Lite(Java). Can you please let us know about your latest position on the proposal? http://marc.theaimsgroup.com/?t=10056072667r=1w=2 Thanks, dims = Davanum Srinivas - http://jguru.com/dims/ __ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[POLL] WASP Lite on Apache?
Background: WASP Lite for Java is a Web services framework developed by Systinet that supports SOAP 1.1, WSDL 1.1, and XML Schema 1999/2000/2001. Details, including binaries and documentation, can be found at http://www.systinet.com/products/wasp_lite/index.html. The product is currently distributed under a free commercial binary license. It has a large user base, many of whom have requested that we make the source available. A number of companies and individuals have expressed interest in contributing to the development of this code. The code has been developed using a modular approach, which should make it relatively easy for others to get comfortable with the code, and which should allow easy sharing of code with the SOAP and Axis projects. We would like to submit this proposal to the members of the Apache XML project for consideration of accepting this donation as a sub-project. Thank you very much for your attention to and consideration for this proposal. We look foward to your questions, comments, or concerns. Anne Thomas Manes CTO, Systinet (formerly Idoox) www.systinet.com - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] WASP Lite on Apache?
Sorry for cluttering up your mailbox -- I'm not sure why this was sent around again. As you can see, it was sent it on Monday. We plan to proceed by submitting the code to the Axis project. Best regards, Anne -Original Message- From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]] Sent: Monday, November 12, 2001 3:40 PM To: General@Xml. Apache. Org Subject: [POLL] WASP Lite on Apache? Background: WASP Lite for Java is a Web services framework developed by Systinet that supports SOAP 1.1, WSDL 1.1, and XML Schema 1999/2000/2001. Details, including binaries and documentation, can be found at http://www.systinet.com/products/wasp_lite/index.html. The product is currently distributed under a free commercial binary license. It has a large user base, many of whom have requested that we make the source available. A number of companies and individuals have expressed interest in contributing to the development of this code. The code has been developed using a modular approach, which should make it relatively easy for others to get comfortable with the code, and which should allow easy sharing of code with the SOAP and Axis projects. We would like to submit this proposal to the members of the Apache XML project for consideration of accepting this donation as a sub-project. Thank you very much for your attention to and consideration for this proposal. We look foward to your questions, comments, or concerns. Anne Thomas Manes CTO, Systinet (formerly Idoox) www.systinet.com - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] WASP Lite on Apache?
Stefano, Sorry that I have't responded to the discussion -- I've been on a plane all day. Before initiating this poll, I discussed it with Sam. I first suggested submitting WASP to Axis. Sam suggested that we set it up as a separate project. But we're happy to abide by the community's decision. As Sam said, Axis supports JAX/RPC. WASP supports JAXM. WASP also supports pluggable transports, pluggable XML protocols, pluggable header processing, pluggable encoding, and pluggable serializers. I saw a recent note from James Snell saying that he was making a fairly significant architecture change to Axis to support pluggable transports. I think there will be lots of opportunity to steal/merge code across the two code bases. I just don't want there to be a huge disruption in Axis to make it happen. Regards, Anne -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 4:49 AM To: [EMAIL PROTECTED] Subject: Re: [POLL] WASP Lite on Apache? Anne Thomas Manes wrote: Stefano, I'm pleased that you think it's a good thing. To clarify: I was commenting Sam's note on I am looking forward to increased synergy and participation. Increased synergy is what I believe it's a good thing. Whether or not making WASP Lite an apache subproject, *this* is yet to be clarified to my eyes. Just to make sure that everybody understands this distinction: synergy *automatically* generates better communities. Competing projects, normally, do not. So to be crystal clear: synergy - good thing competing subprojects - not so sure We first thought of submitting WASP Lite to Axis, but after consideration determined that this approach would be too disruptive and technically challenging. Who considered that? you or the axis community? WASP Lite is a complete code base, and it would be very difficult to attempt to merge this code base with the Axis code base. Oh, believe me, you'd be surprised on how creative people can become if they are really interested in something. Any merger attempt would significantly delay both projects. We don't want to disrupt the Axis project. We share the same concerns though. Let us understand whether or not the move you propose goes in this direction or not. At the same time we think that the open source community will definitely benefit from WASP Lite. Oh, I don't question that. If Sam says so, I trust his technical judgement. But you didn't state We think that a separate project is the better way to go. I thank you very much for your suggestion and will be taken into very high consideration, but please keep in mind that it's up to the apache communities to decide what to do with donated code. If you decide to donate it in order to communities to benefit, it should not be your concern where the code ends up living, but should be the community's itself. Over time Axis and WASP Lite are likely to share code. Perhaps the projects might eventually converge. This wouldn't be the first time we've had competing projects at Apache (Crimson/Xerces/Xerces2 comes to mind). Exactly. We got burned big time by the politics involved in this very example and we DO NOT want this to happen again since we wouldn't have the energy to do this over again. It is exactly because of this example that I'm seriously concerned about having competing subprojects. Note: we have rules that allow committers of one project to propose an internal fork of the subproject itself, then is the community to decide what to do, but this doesn't separate them. If some of your guys are already committers of Axis and you think your solution is better from a technical perspective, then why don't you propose an internal fork with a new codename and work from there? I think it just goes to show that the community is very interested in the technology. Sorry, I can't follow you. I asked explicitly for overlap analysis in order to understand why you propose a different subproject but I didn't get that answer. Now, if you care about the interest of the community is should not matter where the code ends up living or what name it will end up having. Right? If you are so concerned about the name and the location, it only goes to show me that you are more interested in its location and its visibility than to the community interests. But I sincerely hope you can prove me wrong. So, let's get to the point: I'm personally against having two competing subprojects for no technical reason, no matter what they do. Technical competition should happen inside an existing community, following the Rules for revolutionaries. So, either somebody explains those technical reasons in detail (and convices me of the value of having two competing communities), or my vote remains a +1 on the acceptance of the code donation, but as a -1 on the creation of a new subproject. DISCLAIMER: having
RE: [POLL] WASP Lite on Apache?
Stefano, I'm pleased that you think it's a good thing. We first thought of submitting WASP Lite to Axis, but after consideration determined that this approach would be too disruptive and technically challenging. WASP Lite is a complete code base, and it would be very difficult to attempt to merge this code base with the Axis code base. Any merger attempt would significantly delay both projects. We don't want to disrupt the Axis project. At the same time we think that the open source community will definitely benefit from WASP Lite. We think that a separate project is the better way to go. Over time Axis and WASP Lite are likely to share code. Perhaps the projects might eventually converge. This wouldn't be the first time we've had competing projects at Apache (Crimson/Xerces/Xerces2 comes to mind). I think it just goes to show that the community is very interested in the technology. Regards, Anne -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 3:00 PM To: [EMAIL PROTECTED] Subject: Re: [POLL] WASP Lite on Apache? snip This is indeed a good thing. Now, a technical question: we already have two projects which have a pretty high overlap (SOAP and Axis). Why do we need another one? Can't this WASP lite be donated as directly to Axis instead of creating yet another project on webservices? I admit my total ignorance on the problems and this is why I'm asking without stating a vote, but it looks to me that we don't need more subprojects for web services and if this was the case, I would like to treat them as internal competing branches, rather than external subprojects. So, please, enlighten me. Thanks. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. [EMAIL PROTECTED] Friedrich Nietzsche - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[POLL] WASP Lite on Apache?
Background: WASP Lite for Java is a Web services framework developed by Systinet that supports SOAP 1.1, WSDL 1.1, and XML Schema 1999/2000/2001. Details, including binaries and documentation, can be found at http://www.systinet.com/products/wasp_lite/index.html. The product is currently distributed under a free commercial binary license. It has a large user base, many of whom have requested that we make the source available. A number of companies and individuals have expressed interest in contributing to the development of this code. The code has been developed using a modular approach, which should make it relatively easy for others to get comfortable with the code, and which should allow easy sharing of code with the SOAP and Axis projects. We would like to submit this proposal to the members of the Apache XML project for consideration of accepting this donation as a sub-project. Thank you very much for your attention to and consideration for this proposal. We look foward to your questions, comments, or concerns. Anne Thomas Manes CTO, Systinet (formerly Idoox) www.systinet.com - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] UDDI4J on Apache?
+1 Anne Thomas Manes CTO, Idoox -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 10, 2001 7:01 AM To: [EMAIL PROTECTED] Subject: [POLL] UDDI4J on Apache? Background: UDDI4J is an existing Open Source project, hosted on IBM DeveloperWorks and under the IBM Public License. Details, including source code, can be found at http://oss.software.ibm.com/developerworks/projects/uddi4j. More information on the specification which this code implements can be found at http://www.uddi.org/. Another company has approached IBM and expressed an interest in contributing, but expressed reservations based on where it was hosted, and requested that we consider transferring it to a neutral location. As this code complements and works closely with Apache SOAP and Axis, Apache seemed like a natural fit. This other company readily agreed. Approximately six active developers are associated with this project at this time. We expect this number would increase should it be accepted as an Apache XML subproject. General Approach: Java package names would be renamed to org.apache.uddi. All Java source files will contain headers based on the ones found in the Apache SOAP package (essentially the Apache license) The cvs repository, mailing list, and the web site will be hosted on apache.org Comments, questions, concerns? - Sam Ruby - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
