Sam Ruby wrote: > > Simply scheduling all Paces which are not obviously withdrawn, results in: > > = Currently Under Discussion By WG = > PaceAnchorSupport
-1. Separation of concerns. If there are microformats people following who claim they need/want this, I would consider changing to 0. > PaceCategoryListing +0 only because I am unsure of the mechanism proposed, it looks bloated (I might come back with questions), but listing categories is valuable. > PaceClarifyMediaResourceLinks +0 > PaceClarifyTitleHeader +1 > PaceDifferentRelValue +1 > PaceDontUseContentSrc +0 > PaceEditLinkMustToMay +1 > PaceExamples05 +0. Since the pace is out of the date, the editors will need to pick these apart if accepted. I'd suggest the WG review all examples for implicit or contradictory specifications. I see James T for one has already done so. > PaceLinkIntrospection -1. Doesn't pertain to APP directly, should be a separate draft. > PaceMissingDraftHasNoMeaning +1 > PacePreserveForeignMarkup +1. I think the text will be tweaked if accepted. > PaceRemoveMemberTypeMust +1 > PaceRemoveMemberTypePostMust +1 > PaceRemoveTitleHeader -0 If we seem to be adding these as we go, ie the number of headers ends up open-ended I might revert to +1 and refer people to RDF for this kind out of line metadata. > PaceRequestURI +0 It's a nice feature for authors, but I was close to -1 due to underspecification for developers. I have some questions: is the ".atom" postfix a requirement on the server? is 'href' subject or not-subject to xml:base processing? are trailing '/' and '#' or preceding '#' significant? has the spam potential of this feature for SEO been considered? If this makes it, the editors will probably add impl-oriented notes in the draft calling out some issues. I speculate that to get any kind of interop, we'll end up getting the server to inform client show it constructs URIs (which could reintroduce uri-templates) > PaceServiceMayHaveWorkspaces -1. Having at least one workspace gives clients and servers something to agree on. A burden of proof is required here (imo). The argument that forcing servers to expose a workspace will result in junk interop is not made. The conceivable cases mentioned are not enumerated. > PaceServiceShouldHaveWorkspaces As above. > PaceSparqlLink 0 to the idea. SPARQL is still a W3C WD. For all we know this is the could take as long as XQuery plus SW community has a history of chopping and changing query languages (I don't believe this is FUD btw). -1 to the pace. I have no idea where this feature would go within APP. Can the author(s) revisit and represent in terms of spec text? > PaceTitleHeaderOnlyInMediaCollections +0 > PaceTwoPrimaryCollections +1. [I wonder if we are going to end up needing 'accept' for collections] > PaceWorkflows -1. I understand the rationale for removing app:draft, plus I like the idea of keeping APP cruft out of Atom entries for layering reasons, but in the absence of some other mechanism (presumably collection based) I object to taking the feature away due to inelegance. "app:draft is unnecessary" - I find that absurd given more than two server implementations. Getting your hands and manipulating entries in draft state is as close to a universal requirement/behaviour for syndication as I can think of. I'll refer us back to Obasanjo's point from last year. We need a way to give the client a list of drafts. Please propose an alternate mechanism before dropping the only one we have. "Furthermore, it addresses only a small subset of work-flow problems. " True. However 1) anyone who wants to worry about workflow problems can go and check out the WfMC to see the size of that effort, 2) drafting is far and away the dominant workflow problem on our plate. > PaceWorkspaceMayHaveCollections -1. Rationale as per PaceServiceMayHaveWorkspaces above. > PaceWorkspaceShouldHaveCollection -1. Rationale as per PaceServiceMayHaveWorkspaces above. cheers Bill
