Re: Namespaces

Andreas Hartmann <[email protected]> writes:

> > I would suggest that we don't produce XML that does not
> > belong to a namespace - that causes problems that are
> > hard to trace. Shall I add this to our style-guide page?
> 
> I would still suggest to use namespaces for all XML documents.
> The question is which base URI we shall use. Any suggestions?

lenya.org?

Why don't you come up with a little RFC?

It's all fine to come up with a standard describing how we ought to do
it. But acyualy updating all existing publications to this scheme is a
non-trivial amount of work.

That's why I'd like to see some outline how or if we are going to move
existing publications to this new standard. If we decide not to move
them that's ok and should also be noted.

e.g. you could for example use the Python PEPs as an inspiration

1. Preamble -- RFC822 style headers containing meta-data about the
   PEP, including the PEP number, a short descriptive title
   (limited to a maximum of 44 characters), the names, and
   optionally the contact info for each author, etc.

2. Abstract -- a short (~200 word) description of the technical
   issue being addressed.

3. Copyright/public domain -- Each PEP must either be explicitly
   labelled as placed in the public domain (see this PEP as an
   example) or licensed under the Open Publication License[4].

4. Specification -- The technical specification should describe
   the syntax and semantics of any new language feature.

5. Motivation -- The motivation is critical for PEPs that want to
   change the Python language.  It should clearly explain why the
   existing language specification is inadequate to address the
   problem that the PEP solves.  PEP submissions without
   sufficient motivation may be rejected outright.

6. Rationale -- The rationale fleshes out the specification by
   describing what motivated the design and why particular design
   decisions were made.  It should describe alternate designs that
   were considered and related work, e.g. how the feature is
   supported in other languages.

   The rationale should provide evidence of consensus within the
   community and discuss important objections or concerns raised
   during discussion.

7. Backwards Compatibility -- All PEPs that introduce backwards
   incompatibilities must include a section describing these
   incompatibilities and their severity.  The PEP must explain how
   the author proposes to deal with these incompatibilities.  PEP
   submissions without a sufficient backwards compatibility
   treatise may be rejected outright.

8. Reference Implementation -- The reference implementation must
   be completed before any PEP is given status "Final", but it
   need not be completed before the PEP is accepted.  It is better
   to finish the specification and rationale first and reach
   consensus on it before writing code.

   The final implementation must include test code and
   documentation appropriate for either the Python language
   reference or the standard library reference.

-- 
Christian Egli       [email protected]   +41 1 272 9161
                     Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS      http://www.wyona.org http://www.wyona.com