Re: Revisions to xml.apache.org charter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ted, Comments/thoughts in-line. Take with grain of salt. I haven't attempted to create new text, and am not sure what process you want to follow to evolve this document to final form. Cheers, ~Berin Ted Leung wrote: | Hi All, | | | | Here is a first cut at a revised charter for xml.apache.org. This is | just a starting point, | | so please comment, etc. | | | | I've included the text and diffs inline. I've also committed this | version to xml-admin. | | | | Ted | | --- | | xml.apache.org is a collaborative software development project | | dedicated to providing robust, full-featured, commercial-quality, and | | freely available XML support on a wide variety of platforms. This | | project is managed in cooperation with various individuals worldwide | | (both independent and company-affiliated experts), who use the | | Internet to communicate, plan, and develop XML software and related | | documentation. | | | | This charter briefly describes the mission, history, organization, and | | processes of the project. | | | | MISSION | | === | | xml.apache.org exists to promote the use of XML. We view XML as a | | compelling paradigm that structures data as information, thereby | | facilitating the exchange, transformation, and presentation of | | knowledge. The ability to transform raw data into usable information | | has great potential to improve the functionality and use of | | information systems. We intend to build freely available XML | | processing components in order to engender such improvements. | | | | xml.apache.org defines a set of components that exchange or deal with | | XML information sets. These components plug into each other using | | standard APIs (formal, de facto, or proposed). The components must be | | high performance, reliable, and easy to use. The components must be | | part of an underlying architectural orchestration that will allow them | | to work together without major negotiations or breakage. | | | | We believe that the best way to define this XML information exchange | | architecture is by having both individuals and corporations | | collaborate on the best possible infrastructure, APIs, code, testing, | | and release cycles. Components must be vendor neutral and usable as | | core components for all. | | | | In order to achieve a coherent architecture between xml.apache.org | | components and other components and applications, standards (formal or | | de facto) will be used as much as possible for both protocols and | | APIs. We will also allow the innovation of new protocols, APIs, and | | components in order to seed new concepts not yet defined by standards. | Do we see it as part of the charter to also provide feedback into the developing standards from other forums (e.g. w3c)? Maybe where applicable? (There is an implication of this below.) | | | HISTORY | | === | | | | This project was established under the direction of the newly-formed | | Apache Software Foundation in August 1999 to facilitate joint | | open-source development. | | | | THE PROJECT MANAGEMENT COMMITTEE | | | | The xml.apache.org project is managed by a small, core group of | | contributors known as the Project Management Committee [PMC]. The PMC | | must have at least one officer from the Apache Board, who will be the | | Chairperson and report to the Apache Board. See | | http://www.apache.org/foundation/bylaws.html for reference. The | | Chairperson will serve a term of one calendar year | | | | The PMC has the following responsibilities: | | | | 1) Accepting new subproject proposals, formally submitting these | |proposals for committer vote, and creating the subproject (see | |SUBPROJECTS below). | | 2) Facilitating code or other donations by individuals or companies. | | 3) Resolving license issues and other legal issues. | | 4) Approving new committers. I thought this was de-volved to the sub-projects? | | 5) Ensuring that administrative and infrastructure work is completed. | | 6) Facilitating relationships among projects. And sub-projects? | | 7) Facilitating relationships between xml.apache.org and the external | |world. | | 8) Overseeing xml.apache.org to ensure that the mission defined in | |this document is being fulfilled. | | 9) Resolving conflicts within the project. | | | | To become a member of the PMC, an individual must be nominated by a | | contributor, unanimously approved by all PMC members, and approved by | | a two-thirds majority of committers. In most cases, developers will | | have actively contributed to development for at least six months | | before being considered for membership on the PMC. | | Is this all xml.apache.org committers? The process recently gone through is fairly different - 2 people per sub-project, voted in by committers on the sub-project. Maybe this should now be updated to reflect the new approach? The
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]
Re: Namespaces inherited?
At 2:21 PM -0500 3/13/03, Watts, Tim T wrote: 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 The book is wrong. These are not equivalent. In the first example elemB is in no namespace. It is most definitely *not* in the urn:myNS namespace. -- +---++---+ | Elliotte Rusty Harold | [EMAIL PROTECTED] | Writer/Programmer | +---++---+ | Processing XML with Java (Addison-Wesley, 2002) | | http://www.cafeconleche.org/books/xmljava | | http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA | +--+-+ | Read Cafe au Lait for Java News: http://www.cafeaulait.org/ | | Read Cafe con Leche for XML News: http://www.cafeconleche.org/| +--+-+ - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Namespaces inherited?
Hi Tim, A general XML development list would probably be a better place to discuss issues like this than this list--whose primary purpose is to discuss issues common to multiple xml.apache.org projects... Anyway: No, the two examples are certainly not semantically equivalent. It is true that descendant are in the scope of namespace prefixes declared by their ancestors. But the first elemB doesn't actually use the namespace prefix declared in its parent, so it isn't in that namespace; the second does, therefore it is in the same namespace as the parent. Hope that helps, Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] |-+- | | Watts, Tim T| | | [EMAIL PROTECTED]| | | merica.com | | | | | | 03/13/2003 02:21 PM | | | Please respond to | | | general | | | | |-+- -| | | | To: [EMAIL PROTECTED] | | cc: | | 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: Namespaces inherited?
Ok, thanks. I'll sleep much better tonight! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 2:33 PM To: [EMAIL PROTECTED] Subject: Re: Namespaces inherited? Hi Tim, A general XML development list would probably be a better place to discuss issues like this than this list--whose primary purpose is to discuss issues common to multiple xml.apache.org projects... Anyway: No, the two examples are certainly not semantically equivalent. It is true that descendant are in the scope of namespace prefixes declared by their ancestors. But the first elemB doesn't actually use the namespace prefix declared in its parent, so it isn't in that namespace; the second does, therefore it is in the same namespace as the parent. Hope that helps, Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] |-+- | | Watts, Tim T| | | [EMAIL PROTECTED]| | | merica.com | | | | | | 03/13/2003 02:21 PM | | | Please respond to | | | general | | | | |-+- -| | | | To: [EMAIL PROTECTED] | | cc: | | 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] - In case of troubles, 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: Revisions to xml.apache.org charter
Peter B. West wrote: a two-thirds majority of committers. Again, which committers? Indeed, given that there are usually quite a few inactive committers for a specific (sub-)project. It might be necessary to keep records of committers currently eligible for 2/3 majorities J.Pietschmann - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Revisions to xml.apache.org charter
J.Pietschmann wrote: Steven Noels wrote: Voting should be made a requirement for _releases_ IMHO. ...and other important decisions, subject to common sense. For example: - major non-incremental design changes if consensus exist: dunnow otherwise: +0.5 is voting a method of gauging consensus? or should we install some flame metering instead? :-) - branching +1 - public API changes, in particular if other Apache projects are known to be affected (should they have a vote too? :-) Oh sure, why not. ;-) Seriously: I really don't know. Avalon is kind enough to check on Cocoon prior to changing APIs we depend on, but I regard that as a very kind courtesy and as such, I value this much more than when they would do the same just because of rules and regulations. I like it when people are doing Good Things without being expected to do so. My nitpicking was based on the _required_ votes. I think we should have as little required votes as possible. Informal consensus gauging by exchanging +1/-1 are already part of our life and vocabulary. (I sometimes even see myself replying to customer emails with only +1 in the body if I'm OK with what they said.) Totally OT: as a non-native English speaking guy, I've been smiling today because of the similarity between 'vote' and 'veto'. There's some beautiful coinciding tongue-in-cheek humor behind that, especially if you look at recent discussions on some lists. But I'm digressing... ;-) /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Revisions to xml.apache.org charter
Joerg, I hadn't even thought of that. My general concern was to have spelled out the circumstances in which a) all committers on XML sub-projects or b) all committers on a particular sub-project are being referred to. It's not enough to rely on context. Your point is, of course, valid. Peter J.Pietschmann wrote: Peter B. West wrote: a two-thirds majority of committers. Again, which committers? Indeed, given that there are usually quite a few inactive committers for a specific (sub-)project. It might be necessary to keep records of committers currently eligible for 2/3 majorities -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Revisions to xml.apache.org charter
Steven Noels wrote: My nitpicking was based on the _required_ votes. I think we should have as little required votes as possible. Indeed. There should be some common sense and perhaps tradition applied to what's voted on. I think the charter can mention important issues regarding the codebase, with releases to be explicitely declared important, perhaps a few examples what's *usually* considered important, and leave details to the community. Of course, any issue a committer initiates a vote about is automatically raised to important status. J.Pietschmann - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
