Documentation / governance

[ferrisoxide]

Hi folks

I'm keen to get some structure in the way we put the XPCA spec
together. I've always admired the Python PEP model and - in keeping
with the principle of not reinventing things - I propose we adopt this
model for capturing XPCA specifications.

Under this model we would have a uniquely document per component of
the architecture (e.g. XEP 012: Mapping to Modbus), with each document
requiring a reference implementation to be built as part of the
process getting the approval of the group (same as PEP).

See http://www.python.org/dev/peps/pep-0001/ for an overview of the
PEP process.

My thoughts are that having some kind of document model will help us
give shape to what we're doing - and motivate us to actually get it
done. But also I think it could be useful as a model for production
systems. Aligning this with the idea of having non-prescriptive
"recipes", an implementation of an XPCA system could declare which
parts of XPCA spec it uses - just by identifying with XEP (or whatever
name they are given) it implements. Lots of other wild thoughts, but
I'll leave them until they are fully formed.

What do you think?

Cheers
Tom

[Aleksey Timin]

Using many light and open recipes instead of hard standard is best way
in future for opened technology)
I don't know detail of PEP, but its model is liked me.
But how XEP will support a versions? For example, you publish a new
XEP-001. After some time you have addition for describe new features.
It's the new XEP-002 which consist new functions and reference on
XEP-001 for basic functional?

Aleksey

2011/8/13 ferrisoxide <ferri...@gmail.com>:

> Hi folks
>
> I'm keen to get some structure in the way we put the XPCA spec
> together. I've always admired the Python PEP model and - in keeping
> with the principle of not reinventing things - I propose we adopt this
> model for capturing XPCA specifications.
>
> Under this model we would have a uniquely document per component of
> the architecture (e.g. XEP 012: Mapping to Modbus), with each document
> requiring a reference implementation to be built as part of the
> process getting the approval of the group (same as PEP).
>
> See http://www.python.org/dev/peps/pep-0001/ for an overview of the
> PEP process.
>
> My thoughts are that having some kind of document model will help us
> give shape to what we're doing - and motivate us to actually get it

> done. But also I think it could be useful as a model for productionf

[ferrisoxide]

Once a standard / recipe is published you wouldn't be able to make
changes. Instead you would publish a new standard that deprecates the
original, e.g. say XEP-022 "Address Spaces" gets written and used for
a while. Then someone comes up with a better idea and XEP-078
"Advanced Address Spaces" gets published. XEP-078 would contain a
reference to the earlier spec and the earlier XEP would be marked as
"withdrawn" (or similar). This is how I understand how the PEP system
works.

This is also similar to the IETF RFC documents governing what is a
valid protocol on the internet - earlier documents can be marked as
deprecated by later documents.

On Aug 13, 8:47 pm, Aleksey Timin <ati...@gmail.com> wrote:
> Using many light and open recipes instead of hard standard is best way
> in future for opened technology)
> I don't know detail of PEP, but its model is liked me.
> But how XEP will support a versions? For example, you publish a new
> XEP-001. After some time you have addition for describe new features.
> It's the new XEP-002 which consist new functions and reference on
> XEP-001 for basic functional?
>
> Aleksey
>

> 2011/8/13 ferrisoxide <ferrisox...@gmail.com>:

>
> > Hi folks
>
> > I'm keen to get some structure in the way we put the XPCA spec
> > together. I've always admired the Python PEP model and - in keeping
> > with the principle of not reinventing things - I propose we adopt this
> > model for capturing XPCA specifications.
>
> > Under this model we would have a uniquely document per component of
> > the architecture (e.g. XEP 012: Mapping to Modbus), with each document
> > requiring a reference implementation to be built as part of the
> > process getting the approval of the group (same as PEP).
>

> > Seehttp://www.python.org/dev/peps/pep-0001/for an overview of the