Re: Namespaces

Christian Egli wrote:
> 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?

I would propose just "lenya" as namespace.

> 
> 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.

Well, that's where XSLT comes into play. But yeh, yeh, there will be 
some hands-on as well I guess.

Thanks

Michael

> 
> 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.
>