Re: AtomPubIssuesList for 2006/08/07

On 7/8/06 7:19 PM, "Sam Ruby" <rubys-3fC3ffmUg3LVOl8nZxlIqg@xxxxxxxxxxxxxxxx> 
wrote:

>  PaceAPPCategories

-0

I believe it could be possible to use app collections to maintain sets of
metadata, whether it be lists of categories, or lists of authors, etc.
There's a generalised solution available, imho.

>  PaceAppModified
>  PaceAppModifiedAndEtag

-1 because of the warts of app:revision, app:etag

>  PaceAppModified2

+1 no warts, although slight wording change requested:
    
    s/updated/modified/

    "Publishers MUST change the value of this element every time a
collection member resource has been updated, or an associated Media Resource
has been modified."

(do we really want assholes arguing what the meaning of "updated" is,
especially in light of the existence of atom:updated?)


>  RemoveMustOrderCollectionsByUpdated

-1 leaves sort order undefined, makes life difficult. If server wants to
extend app by making additional feeds available for a given collection
sorted by something other than app:modified they can provide a link in the
serv:collection element.


>  PaceAppUpdated

-1 servers determine app:modified, authors determine atom:updated.

>  PaceCategoryLink

+0

>  PaceExtendIntrospection

+1

>  PaceNoChangeId

+1 if you want a new id, POST a new entry, DELETE the old entry

>  PaceOneAppNamespaceOnly

+1

>  PaceRemoveTitleHeader2

+1

>  PaceRequireContentType

+1 though would prefer SHOULD over MUST

>  PaceSlugHeader4

+1

>  PaceTitleSafety

+1

>  PaceUnifiedEntryEditing

-0

>  UseElementsForAppCollectionTitles

+0

>  PaceConfigurableCollectionOrdering2
>  PaceConfigurableCollectionOrdering

-1 life is complicated enough, and shouldn't this meta information as to
which was a collection feed is sorted be exposed in the services document?

e.