On the plus side, I can see how it's annoying, but I'm -1 on this.
1. the pub:control element strikes me as both unstable and innovative -
ie I'll be a monkey's uncle if it doesn't get embraced and extended. if
it doesn't exist people won't key off it, they'll invent their own
stuff. Document management types are notorious for imposed fine grained
but essentially private business processes in formats. Having it there
means somebody has to justify why some private extension that ultimately
locks in client software is being proposed.
2. starting with two namespaces from day will help educated developers
on the extensibility issues.* You can interpret this as social
engineering, but it would be unkind.
cheers
Bill
* aside: something I learned from versioning formats. If you intend to
have versions then you must ship with two versions; it's the only way to
tease out the issues and stop implementors inserting frozen accidents
into the network. Extensions have similar dynamics.
James M Snell wrote:
http://www.intertwingly.net/wiki/pie/PaceUseOneNamespace
#pragma section-numbers off
== Abstract ==
Minor issue. Use one namespace URI for both the introspection doc and
the pub:control element
== Status ==
Proposed
== Rationale ==
Just a minor issue that I came across when implementing support for
pub:control. The current APP draft currently uses two different
namespace URI's for the pub:control and introspection documents. Even
tho the two are intended for two completely different purposes, there
doesn't appear to be much justification for using two different namespaces.
== Proposal ==
Change section 11.1 to:
{{{
This specification defines an Atom Format extension for publishing
control called Atom Publishing Control.
}}}
Change section 11.2 to:
{{{
11.2 The "app:control" Element
namespace app = "http://purl.org/atom/app#";
pubControl =
element app:control {
atomCommonAttributes,
pubDraft?
& extensionElement
}
pubDraft =
element app:draft { "yes" | "no" }
The "app:control" element MAY appear as a child of an "atom:entry" which
is being created or
updated via the Atom Publishing Protocol. The "app:control" element, if
it does appear in an
entry, MUST only appear at most one time. The "app:control" element is
considered foreign
markup as defined in Section 6 of [RFC4287].
The "app:control" element and its child elements MAY be included in Atom
Feed or Entry Documents.
The "app:control" element MAY contain exactly one "app:draft" element as
defined here, and
MAY contain zero or more extension elements as outlined in Section 6 of
[RFC4287]. Both
clients and servers MUST ignore foreign markup present in the
app:control element.
11.2.1 The "app:draft" Element
The number of "app:draft" elements in "pub:control" MUST be zero or one.
Its value MUST be
one of "yes" or "no". A value of "no" means that the entry MAY be made
publicly visible. If
the "app:draft" element is missing then the value MUST be understood to
be "no". The app:draft
element MAY be ignored.
}}}
== Impacts ==
== Notes ==
----
CategoryProposals
