Regarding EchoExample,
[AaronSw] I think that we should have one proposal, take comments on it, and then modify the proposal based on the comments. If there's an argument about what should be done, we discuss it. If it's a big issue (like inline v. quoted) we take it to another page. I think this system will allow us to get work done faster with less duplication.
[JamesSnell] I say we have multiple proposals that illustrate different points of view and work to bring those together.
[AaronSw] That sounds like just making more work for ourselves. First we have to create divergent proposals, then we have to bring them together? Sure, if people feel differently about an issue, they should have an alternate proposal, but it seems silly to just make different proposals for the fun of it.
[DannyAyers] (head down to avoid flying debris) It would be nice to see links back the the relevant parts of the ConceptualModel, to show where different parts came from.
-
[ChrisWilper] +1. At the very least. Seems like a lot of the things that were being discussed in the ConceptualModel were moved over to the syntax and now semantic and structure discussions are mixed. related blog entry here
[JamesSnell] It's not for the fun of it, it's about being able to see and compare the different options.
[AaronSw] Then do it on a per-option basis, so we can see each option in isolation, and do it next to the discussion of the different options.
[ArveBersvendsen] I'm with AaronSw here, one proposal, big issue discussions moved to specific pages. I'd also think it would be nice if we had a list of changes: Who made what change and why.
[TimBray] Can someone please tidy up all the junk in the bottom two-thirds of the page, it's not obvious where to put proposals aimed at the latest incarnation.
[AaronSw] OK, done.
[TimothyAppnel] +1 Aaron. I'll add that I think we're missing consensus on the principle the syntax will be built on and would provide better clarity and focus to the discussion of what bits and how.
[GrantCarpenter] +1 for more completely resolving the what before proceeding to the how.
[ChrisWilper] +1 Grant. It seems the reason there is reluctance to discuss several options for syntax is really that the data model is (whether formally acknowledged or not) being discussed at the same time. Yes, I'd hate to carry on multiple syntax discussions if the data model was being discussed in each at the same time.
[KenMacLeod] +1. I think we're all on the same page, but emphasising for the casual reader: Beware the risk of using representations in creating a ConceptualModel. While I believe we have consensus that the normative definition of a WellFormedEntry will be defined as part of its interchange syntax, jumping to use the syntax to perform modeling is premature. Use representations as examples of differences between models, but don't let syntax drive the model. Follow the RoadMap. Let me draw people's attention specifically to the fact that while we have defined attributes of an entry, we have not, in fact, defined what an entry is.
-
[BillDehora] Without sounding dense, but what would a WellFormedEntry be other than TheSumOfItsAttributes? The operational discussion is, what are those attributes and how are they related? As for the dangers of delving into syntax, sure, but you can't express or talk about a model without syntax or some form of inscription - lets not get too abstract.
[KenMacLeod] How an entry is used (modeled in relation to other entities like feeds or sites or other things used in a weblog tool) affects what it means to "be" an entry, and thus what attributes should be required and how they are defined. For example, IsaCommentAnEntry, and see also WhatIsAnEntry.
A concrete example, if I take an image created and titled by someone else and "make it an entry" in my weblog, which creator is put in the <author> element, or how else do we make the distinction between the "entry" and the "source" of the entry? We have to define WhatIsAnEntry first, then say how an entry relates to the things in it.
[SimonWillison] I'm extremely confused about the process for modifying the example. I've proposed an alteration which will eliminate duplicate data in the feed ( EchoFeedWithAuthorRefs ) and it's had some feedback, most of it positive. What do I need to do to get it in to the example feed, where it will gain a higher profile and get some serious discussion about whether or not it should be in the final spec? At the moment discussion has died off and the idea seems to be being forgotten, but I believe it is worth serious consideration and I don't see how it will get that without being added to the example. Do I just add it myself and see what happens?