[11/17/2011 4:41:49 PM] *** Anton de Winter added Jonathan Jackson ***
[11/17/2011 4:42:01 PM] *** Anton de Winter added Clayton Sims ***
[11/17/2011 4:42:05 PM] *** Anton de Winter added Drew Roos ***
[11/17/2011 4:42:09 PM] *** Anton de Winter added Yaw Anokwa ***
[11/17/2011 4:42:12 PM] *** Anton de Winter added Carl Hartung ***
[11/17/2011 4:46:04 PM] Anton de Winter: Hey guys,  created this group chat for OpenRosa API discussions
[11/17/2011 4:46:17 PM] Anton de Winter: see the emails I sent out to the OR Workgroup for more deets
[11/17/2011 4:49:18 PM] *** Anton de Winter added Cory Zue ***
[11/17/2011 4:56:07 PM] Jonathan Jackson: can skype still do public links to chats?
[11/17/2011 4:56:08 PM] Jonathan Jackson: let the JR room know this is herfe.
[11/17/2011 4:57:15 PM] *** Anton de Winter has changed the conversation topic to "OpenRosa API Chat" ***
[11/17/2011 4:57:59 PM] Anton de Winter: cool, found the public URI
[11/17/2011 4:57:59 PM] Anton de Winter: [Thursday, November 17, 2011 4:57 PM] sys: 

<<< skype:?chat&blob=2pSByFPIcAva_JLXE2kR8r2qBavK2_4mlpyViJGZr596luQTeQNe2iZ4CYTF1bkuMMVg5jtheE6CE3zZ_VC7LXv0XY_U556LKY1INu9eDfuOOlAfvv4p7w
[11/17/2011 5:23:28 PM] *** Anton de Winter added Matt Adams ***
[11/17/2011 5:23:44 PM] Anton de Winter: Hey everyone
[11/17/2011 5:23:54 PM] Anton de Winter: welcome to Matt Adams with Radical Dynamic.
[11/17/2011 5:24:54 PM | Edited 5:25:14 PM] Anton de Winter: They're working on a data collection product based on ODK that uses JR (http://www.groupcomplete.com/)
[11/17/2011 5:26:59 PM] Matt Adams: Thanks Anton.
[11/17/2011 8:40:04 PM] Yaw Anokwa: read over the spec...
[11/17/2011 8:40:15 PM] Yaw Anokwa: i don't think any of the metadata should be required.
[11/17/2011 8:41:10 PM | Edited 8:46:40 PM] Yaw Anokwa: it'd also be good if we standardized on what prefix. we use jr: everywhere else, and in metadata we use orx: and that'd clean up the need for attributes on the data node too.
[11/17/2011 8:43:06 PM | Edited 8:48:30 PM] Yaw Anokwa: i think any change you make to the form is a new version. i don't like the version/uiversion thing. i see why it's there and i'm not going to fight it, but i don't like it.
[11/17/2011 8:44:35 PM] Yaw Anokwa: i think we can get rid of fillMechanismUri unless there is a clear usecase.
[11/17/2011 8:48:47 PM | Edited 8:49:47 PM] Yaw Anokwa: do we really need the deprecatedId. is there a clear usecase?
[9:05:00 AM] Cory Zue: +1 on removing the version/uiversion distinction
[9:05:54 AM] Cory Zue: no idea what the fill mechanism is
[9:06:29 AM] Cory Zue: deprecation is a useful concept, though what we do currently, which i don't like, is use the same uid and assume that if the content is different it's an overwrite
[9:06:45 AM] Cory Zue: if we don't think we care about standardizing on the edit workflow am happy to remove it
[9:07:26 AM] Cory Zue: i would also propose getting rid of the "uuid:" "openid:" prefixes in all the examples, unless we actually expect the clients to do that. seems a bit silly to me
[9:08:23 AM] Cory Zue: the jr/orx distinction is a purist one, i think, where jr is an implementation of the orx apis (but also is free to add new stuff). i could take it or leave it
[11:10:50 AM] Anton de Winter: Agreed on namespacing.  We're all using JR:  we should stick to that for 1.0 and can change it for 1.1 if need be.
[11:11:14 AM] Anton de Winter: Also not sure what fill mechanism is for so going to cut it
[11:11:58 AM] Anton de Winter: There was a ton of discussion around having the prefixes (uuid: openid: etc)
[11:12:04 AM] Anton de Winter: so I think in the interest of getting things to 1.0, we should keep it in.
[11:12:16 AM] Drew Roos: the reason for the jr: / orx: split was because jr: was a namespace for xform customizations, and orx: was a namespace to be included in instances
[11:12:48 AM] Drew Roos: and i've also never liked version/uiVersion
[11:13:52 AM] Anton de Winter: yeah, we don't use it properly anyway...  Does ODK?
[11:15:40 AM] Anton de Winter: so I'd suggest that we merge uiVersion and Version (=> Version), which indicates any change inthe xform
[11:16:02 AM] Drew Roos: that shows up as a mushroom for me
[11:16:27 AM] Anton de Winter: ?
[11:17:59 AM] Anton de Winter: What is a mushroom?
[11:18:14 AM] Cory Zue: i think drew is saying that ( = > renders as a mushroom on his skype
[11:18:31 AM] Anton de Winter: oh haha
[11:19:12 AM] Drew Roos: my original plan was an X.Y style version
[11:19:24 AM] Drew Roos: where X ~= version and Y ~= uiVersion
[11:19:43 AM] Drew Roos: can we just put version in the xmlns?
[11:19:55 AM] Clayton Sims: Drew: We discussed that originally
[11:19:58 AM] Drew Roos: we must have found a reason not to the last time 'round
[11:20:38 AM] Clayton Sims: it makes it difficult to recognize the same data without doing a lot more processing
[11:21:19 AM] Drew Roos: "how does every other xml app on the planet handle this?"
[11:21:58 AM] Clayton Sims: the verson/uiversion thing that we used came from an article about how intel deals with this
[11:22:28 AM] Drew Roos: but isn't it clear the uiVersion at least has been a failure?
[11:22:38 AM] Drew Roos: because it's never updated when it's supposed to be
[11:23:00 AM] Jonathan Jackson: if the one group trying to use it correctly hasn't, I would argue yes.
[11:23:07 AM] Jonathan Jackson: doesn't that also mean ouur backend is getting no value out of it?
[11:23:11 AM] Clayton Sims: uiVersion clearly doesn't work
[11:23:17 AM] Clayton Sims: I'm fine with only using one version #
[11:23:37 AM] Clayton Sims: the whole notion of UIVersioin was way, way too long-term
[11:25:05 AM] Anton de Winter: Ok, so I think I'm going to merge the two to just "version" and let it indicate any changes to the form
[11:25:14 AM] Clayton Sims: I think that's a good approach
[11:25:27 AM | Edited 11:25:32 AM] Anton de Winter: Are we settled on ORX: versus JR: ?
[11:25:49 AM] Anton de Winter: Leaning heavily towards making it JR and re-investigating for 1.1
[11:26:07 AM] Clayton Sims: So... I don't get this
[11:26:13 AM] Clayton Sims: you mean for namespaces?
[11:26:18 AM] Anton de Winter: yeah
[11:26:30 AM] Clayton Sims: are you using jr:/orx: as placeholders for hte actual namespaces?
[11:27:01 AM] Clayton Sims: I think openrosa makes the better namespace
[11:27:12 AM] Clayton Sims: but really don't care
[11:29:05 AM] Anton de Winter: I don't think it adds much processing overhead to have it in a different namespace
[11:29:10 AM] Anton de Winter: so maybe it's best to leave it in
[11:29:11 AM] Drew Roos: i think the questoin is same or different namespaces
[11:29:14 AM] Anton de Winter: (it sure doesn't hurt)
[11:29:26 AM] Clayton Sims: Oh, I'm pro same namespaces
[11:29:33 AM] Jonathan Jackson: it should be orx
[11:29:36 AM] Clayton Sims: What do we think should be in a different namespace?
[11:29:37 AM] Jonathan Jackson: its just jr because we made it jr.
[11:29:40 AM] Jonathan Jackson: and never changed it
[11:29:55 AM] Jonathan Jackson: i'm sure of this because I made up the orx namespace
[11:29:56 AM] Drew Roos: @jon you know the prefix is irrelevant
[11:29:59 AM] Jonathan Jackson: with the intentin of it replacing jr
[11:30:22 AM] Jonathan Jackson: yes, its only per form, right?
[11:30:27 AM] Drew Roos: we could replace jr with orx right now as long as you map orx: to the same namespace uri
[11:30:38 AM] Jonathan Jackson: right.
[11:30:45 AM] Drew Roos: though some of the itext stuff expects hard-coded jr:
[11:30:52 AM] Jonathan Jackson: that should change.
[11:31:17 AM] Anton de Winter: that's a implementation problem though.
[11:31:24 AM] Drew Roos: i don't feel a compelling reason to switch from jr:
[11:31:58 AM] Drew Roos: doesn't javarosa as a name have much more traction than openrosa?
[11:31:59 AM] Clayton Sims: Drew, I'm fine with 
jr = http://openrosa.org/
[11:32:30 AM] Drew Roos: xmlns:jr="http://openrosa.org/javarosa"
[11:36:56 AM] Jonathan Jackson: I can live with [11:32:37 AM] Drew Roos: xmlns:jr="http://openrosa.org/javarosa"
[11:37:27 AM] Clayton Sims: rgrgr
[11:38:06 AM] Drew Roos: i thought the orx namespace was intended just for the metadata
[11:38:30 AM] Clayton Sims: I think it should all be in the same namespace
[11:38:38 AM] Jonathan Jackson: I meant it for everything
[11:38:51 AM | Edited 11:38:58 AM] Jonathan Jackson: anything you are doing in the xform should be openrosa portable
[11:39:05 AM] Jonathan Jackson: so nothing is supposed to be jr specific
[11:39:07 AM] Jonathan Jackson: even though it is
[11:39:26 AM] Drew Roos: i don't think we're talking about the same thing
[11:40:17 AM] Drew Roos: like, if we ever wanted to use a schema validator (which admittedly is far-fetched), two namespaces makes more sense
[11:40:58 AM] Jonathan Jackson: I'm saying, nothing you or clayton do in JR is intended to be JR only.
[11:41:14 AM] Drew Roos: everyone is in agreement on that
[11:41:16 AM] Jonathan Jackson: its intended to be able to be supported by anything that supports the full OR spec
[11:41:17 AM] Jonathan Jackson: k.
[11:41:29 AM] Drew Roos: but no one cares if hte xmlns prefix is 'jr' or 'or'
[11:41:50 AM] Drew Roos: since it can already be changed to whatever you want
[11:42:12 AM | Edited 11:42:22 AM] Drew Roos: i'm talking about whether it makes sense for the metadata block to use a different namespace
[11:42:41 AM] Clayton Sims: I don't think it does
[11:56:59 AM] Matt Adams: Hi folks, sorry I'm late to the discussion.  Couple of things I want to chime in with.
[11:57:53 AM] Matt Adams: To echo what others have already said: it makes sense to merge uiVersion & version.  I don't think that having the former as a separate concept helps anything.
[12:01:03 PM] Matt Adams: I'm concerned that the additional constraint of having ID scheme:values no longer than 80 characters is shortsighted.  Can we either remove the requirement altogether or at least increase it to something a little more reasonable: there is a good chance that future implementors may have long registered domain prefixes and these + their respective unique identifiers could quite possibly be longer than 80 characters.  I'd hate to think that people are going to have to maintain a separate mapping of IDs just to work around this limitation.
[12:02:09 PM] Cory Zue: good point, i think it should be removed
[12:07:53 PM] Matt Adams: My opinions on the namespace issues are moot; I don't care very much about them as long as they are uniform across all implementations.  I do not think that any of the namespace requirements should be optional (I'm not saying that this has been proposed so much as this is really my only concern re: namespaces).
[12:11:13 PM] Matt Adams: I think meta should have a separate namespace, too, but see my previous comment (don't care so much as long as the use is consistent).
[12:12:32 PM] Matt Adams: I think the remainder of the spec looks good.  I don't have any questions/concerns about anything else.
[1:24:48 PM] *** Anton de Winter added Ian Robert Lawrence ***
[1:24:58 PM] Anton de Winter: Hey Ian
[1:25:00 PM] Anton de Winter: welcome to the chat
[1:25:17 PM] Ian Robert Lawrence: hi anton
[1:25:21 PM] Ian Robert Lawrence: thanks
[2:52:50 PM] *** Anton de Winter added Jorn Klungsoyr ***
[2:52:50 PM] *** Jorn Klungsoyr can't be added until they accept your contact request. ***
[2:53:24 PM] *** Anton de Winter added Jorn Klungsoyr ***
[2:53:24 PM] *** Jorn Klungsoyr can't be added until they accept your contact request. ***
[2:54:22 PM] Anton de Winter: Contact sent to the group
[2:54:33 PM] Anton de Winter: woops sorry
[2:54:37 PM] *** Anton de Winter added Jorn Klungsoyr ***
[2:54:40 PM] *** Jorn Klungsoyr can't be added until they accept your contact request. ***
[2:55:22 PM] Anton de Winter: Can someone try adding Jorn
[2:55:27 PM] Anton de Winter: for some reason I can't
[2:55:31 PM] *** Yaw Anokwa added Jorn Klungsoyr ***
[2:55:34 PM] Anton de Winter: thanks
[3:02:12 PM] *** Anton de Winter added Gaetano Borriello ***
[3:13:14 PM] Anton de Winter: hey Gaetano
[3:13:34 PM] *** Jonathan Jackson added Mitch Sundt ***
[3:13:46 PM] Jonathan Jackson: ugh, I forgot
[3:13:51 PM] Mitch Sundt: Thanks
[3:13:52 PM] Jonathan Jackson: if you get added you can't see the thread.
[3:14:12 PM | Edited 3:14:19 PM] Jonathan Jackson: Anton - can you take on the super annoying job of copying the message log once a day over to bitbucket as a daily log?
[3:16:02 PM] Drew Roos: 10% project: skype archiver?
[3:16:21 PM] Yaw Anokwa: this is why i wanted to get rid of skype all together. irc has this problem solved..
[3:16:39 PM] Ian Robert Lawrence: campfire?
[3:17:45 PM] Anton de Winter: Irc doesn't have this problem solved?
[3:17:53 PM] Anton de Winter: You mean auto archiving logs somewhere?
[3:17:59 PM] Yaw Anokwa: yea
[3:18:11 PM] Anton de Winter: You'd still have to manually grab the logs and put them somewhere
[3:18:16 PM] Anton de Winter: doesn't skype store logs on disk somewhere?
[3:18:27 PM] Jonathan Jackson: yes, regardless, Anton - say yes.
[3:18:34 PM] Cory Zue: @anton there are irc bots that do all kinds of stuff including posting logs
[3:18:40 PM] Cory Zue: also: /offtopic
[3:18:53 PM] Matt Adams: I'm on #opendatakit right now
[3:19:58 PM] Mitch Sundt: So from Anton's e-mail... 
- where was Fill Mechanism mentioned?  
- Aggregate 1.x looks for the first tag name "metadata" and doesn't particularly care about namespaces.  
- where does uiVersion / version stand now?
[3:20:20 PM] Mitch Sundt: or rather, "meta"
[3:20:22 PM] Jonathan Jackson: mitch, just e-mailed you the entire history.
[3:20:38 PM] Drew Roos: can we also use this as an opportunity to ditch the camelcase?
[3:21:46 PM] Anton de Winter: @mitch, looks like we're agreed on merging uiversion and version into one thing
[3:22:04 PM] Yaw Anokwa: camelCaseForLife
[3:22:07 PM] Jonathan Jackson: Anton - are you editing the spec in real time as this chat comes to a consensus?
[3:22:22 PM] Anton de Winter: yeah
[3:22:34 PM] Anton de Winter: that's why mitch can't find where fillMechanism is mentioned.
[3:24:06 PM] Jonathan Jackson: cool.
[3:24:19 PM | Edited 3:24:28 PM] Jonathan Jackson: can you let folks on ORWG know that?
[3:24:33 PM] Jonathan Jackson: although guessing most are now in this room who care
[3:25:48 PM] Mitch Sundt: So does the meaning of version mean that the set of questions is unchanged but just the ordering or phrasing has changed?
[3:26:08 PM] Mitch Sundt: i.e., the model is invariant
[3:26:31 PM] Jonathan Jackson: there should be only one version now
[3:26:36 PM] Jonathan Jackson: it should change anytime the form is changed.
[3:26:49 PM] Jonathan Jackson: (is my opinion)
[3:27:32 PM] Mitch Sundt: anything in the form, or just the text (e.g., spelling corrections).  If you get rid of one, I would hope it would be the old sense of "version".
[3:27:54 PM] Mitch Sundt: I.e., rev. the version whenever the presentation changes, but rev the form id whenever the model changes.
[3:28:34 PM] Jonathan Jackson: so should we just keep the version language
[3:28:38 PM] Jonathan Jackson: and kill the uiVersion language?
[3:29:10 PM] Yaw Anokwa: my concern here is that no one will actually use the major/minor thing. that aside, changing the wording often changes the survey entirely.
[3:29:21 PM] Matt Adams: Agree.
[3:29:32 PM] Jonathan Jackson: the only real use case is syncing forms right?
[3:29:39 PM] Jonathan Jackson: in which case, you always want the latest form?
[3:30:10 PM] Drew Roos: can't we leave it unspecified what the version changes actually mean
[3:30:28 PM] Drew Roos: if someone wants to use 4,5,6,7 vs 4.0,4.1,4.1.1, let them
[3:31:00 PM] Mitch Sundt: They should be integers only.  Keep it simple.
[3:31:29 PM] Yaw Anokwa: agreed. integers make sense to me.
[3:31:41 PM] Mitch Sundt: The question is whether on the server/aggregator end, you want to be able to fold all the completed forms into the same bucket.  And yet know that they had subtle changes.
[3:32:04 PM] Mitch Sundt: If you change the data representation, by adding new questions, etc., the server merge is more complex and I'm happy to punt that.
[3:32:42 PM] Mitch Sundt: But if you're trying to tease out inconsistency in responses, and altering the question flow, you probably want to combine the data sets into one and run an analysis tool on the results.
[3:32:58 PM] Mitch Sundt: Having no version prevents that.
[3:33:30 PM] Mitch Sundt: Having version be wishy-washy in meaning also prevents it, since the server can't assume the data can be stored in the same repository and format.
[3:33:54 PM] Jonathan Jackson: but Mitch -
[3:34:02 PM] Jonathan Jackson: humans get to enter the version number
[3:34:13 PM] Jonathan Jackson: so the server can't assume they were incremented correctly
[3:34:26 PM] Jonathan Jackson: so you have to fail gracefully anyways in that combining scenario and make a best effort
[3:34:36 PM] Drew Roos: if we're relying on that then what's the point of having hte attribute in the first place
[3:34:44 PM] Anton de Winter: I'd imagine merging data sets like that is usually left to somoene who analyzes the data
[3:34:49 PM] Jonathan Jackson: because you can make a really good best erffort
[3:34:54 PM] Anton de Winter: since it can get really complicated
[3:34:57 PM] Jonathan Jackson: and if you know your machine generated it, then you can trust it
[3:35:02 PM] Drew Roos: does HQ auto-increment the version?
[3:35:05 PM] Jonathan Jackson: yes
[3:35:12 PM] Mitch Sundt: It doesn't need to increment. Just be distinct.
[3:35:14 PM] Jonathan Jackson: (maybe)
[3:36:02 PM] Cory Zue: I don't see why you'd restrict it to integers
[3:36:12 PM] Yaw Anokwa: agreed with anton that human beings can and should do the merge. for me the version number as metadata is just nice thing to help people track versions. they could put it in the form, but it makes things a little more visible.
[3:36:16 PM] Cory Zue: Why shouldn't someone be allowed to use UIDs if they want to?
[3:36:21 PM] Cory Zue: or drew's format
[3:36:57 PM] Jonathan Jackson: I think monotonically increasing version numbers is the way to go.
[3:37:19 PM] Cory Zue: version 81923 is much messier than 6.7.2
[3:37:26 PM] Drew Roos: it seems like the best-faith effort should be on hte receiving end
[3:37:27 PM] Jonathan Jackson: is there an iso way to do a 4 part version?
[3:37:31 PM] Anton de Winter: @Yaw, right, I believe the version is to help humans keep track and shouldn't be relied upon for more complex stuff
[3:37:41 PM] Drew Roos: "i'll try my best to interpret your version #, but if you do something crazy, tough"
[3:38:11 PM] Yaw Anokwa: no way to 4 part version numbers.  no one is going to have version 81923.
[3:38:51 PM | Edited 3:38:54 PM] Clayton Sims: I'm a huge believer in monotonically increasing
[3:39:09 PM] Clayton Sims: version 2543 is way, way better than version 1.2.32.332
[3:39:15 PM] Jonathan Jackson: I'm fine with integers
[3:39:17 PM] Jonathan Jackson: or decimals
[3:39:18 PM] Matt Adams: +1 for simple integers
[3:40:02 PM] Drew Roos: "better" in what sense?
[3:40:38 PM] Anton de Winter: +1 for integers
[3:40:45 PM] Cory Zue: why?
[3:40:52 PM] Cory Zue: you're not making arguments other than "better"
[3:40:52 PM] Matt Adams: if (newVersion > oldVersion) { }
[3:40:54 PM] Clayton Sims: Drew: Better in that it's easier for people to parse and use them reasonably
[3:40:57 PM] Matt Adams: Instead of trying to parse something more complex
[3:41:08 PM] Drew Roos: handling a dotted version # is one line of code
[3:41:11 PM] Cory Zue: strings can be compared too?
[3:41:21 PM] Drew Roos: def normalize_version(v):
  return [int(k) for k in v.split('.')]
[3:41:23 PM] Clayton Sims: If I have version 2.3.2 and version 3.2.1, what does that even mean?
[3:41:34 PM] Drew Roos: is that a serious quesiton?
[3:41:35 PM] Yaw Anokwa: amen, clayton
[3:41:39 PM] Drew Roos: 3 > 2!
[3:41:42 PM] Yaw Anokwa: in general, drew is wrong.
[3:41:45 PM] Clayton Sims: Why force people to do this?
[3:41:54 PM] Cory Zue: it's not a question of forcing it's a question of choice
[3:41:59 PM] Clayton Sims: In software major/minor/maintenance id's make plenty of sense
[3:42:01 PM] Cory Zue: you're the ones forcing a format
[3:42:10 PM] Clayton Sims: for xforms it just seems like mad overkill
[3:42:14 PM] Jonathan Jackson: to be clear, the whole exercise is about forcing a format
[3:42:18 PM] Jonathan Jackson: (of openrosa)
[3:42:23 PM] Cory Zue: "version should be a unique string" is overkill?
[3:42:25 PM] Drew Roos: i hate to get all routen, but monotonic is just a multipart version number with one part
[3:42:38 PM] Yaw Anokwa: Yaw Anokwa rofl
[3:43:04 PM] Jonathan Jackson: is anyone on this chat not going to imlpement this as an int?
[3:43:19 PM] Jonathan Jackson: I woudl content the major thing we should care about is literally just the people in this chat room being able to interoperate
[3:43:21 PM] Jonathan Jackson: for v1
[3:43:28 PM] Clayton Sims: unique string doesn't guarantee comparability
[3:43:31 PM] Clayton Sims: unique integer does
[3:43:42 PM | Edited 3:43:48 PM] Jonathan Jackson: cory, in hq, this will be an int, right?
[3:44:01 PM] Matt Adams: I have certain requirements that are outside of the OpenRosa spec but I'm fine with int; it's easy for us to interoperate with.
[3:44:40 PM] Mitch Sundt: keep in mind that you have a form id.  That tracks different form.
[3:46:02 PM] Mitch Sundt: From the aggregator side, if I know the form id matches, I can verify that the new form (with different version number) generates the same data model as the prior version(s).  Only then would I accept the updated form and make it the current form available for download.
[3:46:08 PM] Cory Zue: do you guys not think software should have minor version numbers?
[3:46:28 PM] Cory Zue: like, do you not think that's a concept that might be useful to someone ever?
[3:46:45 PM] Jonathan Jackson: v1.0 is not shooting for maximal inclusions of any use case ever.
[3:46:47 PM] Mitch Sundt: The version distinguishes presentation changes from data model changes. If the model changes, then the form id should change.
[3:47:05 PM | Edited 3:47:09 PM] Clayton Sims: Cory: I think _software_ should have minor version numbers. I don't think that every thing that is versioned should have version changes
[3:47:06 PM] Cory Zue: mitch, i think most people are actually making the opposite argument
[3:47:11 PM] Cory Zue: a change is a change is a change
[3:47:25 PM] Matt Adams: Agree with Cory on that.
[3:47:31 PM] Jonathan Jackson: agreed: I think most people are saying a change is a change.
[3:47:33 PM] Mitch Sundt: From the aggregator side, I don't care whether the numbers are in order or not.  What is important from my end is that the last-uploaded form be the form that is available for download.
[3:47:37 PM] Yaw Anokwa: i don't like over designing things. i can't think of a scenario where incrementing integers isn't adequate to track changes.
[3:48:04 PM] Matt Adams: Agree also. If it becomes clear that a simple int isn't enough, that can be a v1.1 spec.
[3:48:26 PM] Drew Roos: why not just have a timestamp and call it a day
[3:48:32 PM] Mitch Sundt: IF you don't distinguish between presentation and data model changes, then you should get rid of all version attributes. None.
[3:49:12 PM] Cory Zue: the operation of looking up exactly what generated an instance surely is always useful?
[3:49:39 PM] Mitch Sundt: The value is on the aggregator side- being able to programmatically combine results and allow a continuous data collection effort and seeing that data all flow into the same visualization/analysis pipeline
[3:49:52 PM] Drew Roos: @mitch, i don't think any of us have been able to create a workflow that ensures people reliably distinguish between content and presentation changes to their forms
[3:50:09 PM] Cory Zue: i think there are broader scenarios that matter. for example, changing select item values
[3:50:23 PM] Mitch Sundt: You can compare the data storage model.  If it is different, then it isn't the same form.
[3:50:35 PM] Cory Zue: or changing select item text which alters the meaning of the value
[3:50:51 PM] Cory Zue: that strikes me as a pretty narrow perspective
[3:51:20 PM] Mitch Sundt: It is a perspective that can be accomplished by a program.  It is narrow.
[3:51:51 PM] Cory Zue: but humans also care about the contents of these forms and the version is how we're allowing them to do that
[3:52:07 PM] Mitch Sundt: Any other versioning should generate a different form. The form designer/creator must weigh whether the form is different or the same, whether the meanings are substantially divergent or not.
[3:52:25 PM] Jonathan Jackson: "version:  an integer-valued version number for the XForm.  This should be incremented anytime there is a change to the XForm contents."
[3:52:38 PM] Mitch Sundt: That's form id.
[3:52:48 PM] Mitch Sundt: and it can be any alphanumeric
[3:53:02 PM] Cory Zue: ok, maybe i'm missing something
[3:53:09 PM] Cory Zue: i didn't realize formid was a concept
[3:53:11 PM] Jonathan Jackson: I think i'm missing something too
[3:53:17 PM] Jonathan Jackson: formid -- Jons IMCI form
[3:53:17 PM] Clayton Sims: formid = xmlns
[3:53:22 PM] Jonathan Jackson: v1 = my first attempt to write that
[3:53:23 PM] Drew Roos: is formID distinct from xmlns?
[3:53:25 PM] Jonathan Jackson: v2 = my second attempt
[3:53:59 PM] Drew Roos: to me, all forms with the same form ID are forms you would conceivably want to aggregate together, even with version skew
[3:54:06 PM] Jonathan Jackson: correct
[3:54:09 PM] Yaw Anokwa: yup
[3:54:12 PM] Jonathan Jackson: or tell someone that you relased a new versin of
[3:54:19 PM] Clayton Sims: Drew: Formid serves the same function as xmlns
[3:54:29 PM] Mitch Sundt: it is equivalent.  xmlns="..." defines the form id.  It should be a URI, but most people put in "myform", which is non-conformant.  Form id is the more general any-alphanumeric string.
[3:54:42 PM] Clayton Sims: xmlns doesn't have to have any uri structure
[3:54:47 PM] Mitch Sundt: @Drew - YES.
[3:54:51 PM] Clayton Sims: you can use an arbitrary string for xmlns
[3:55:11 PM] Drew Roos: @mitch version skew includes correcting for data model changes
[3:55:11 PM] Mitch Sundt: This is xmlns at the root element of the model instance.
[3:55:26 PM] Drew Roos: let's call it the xmlns for clarity
[3:55:31 PM] Yaw Anokwa: we design for human beings, no? most people see xmlns as a url, and think of form id as a unique identifier.
[3:55:39 PM] Mitch Sundt: If you want to track model changes, then I'd argue you should have both uiVersion and version.
[3:55:49 PM] Drew Roos: are we actually talking about having a <FormID /> in the <meta> block?
[3:55:57 PM] Mitch Sundt: I can write a program to deal with uiversion easily; version is harder (in this sense).
[3:56:14 PM] Mitch Sundt: No. Form ID is in the top-level instance attribute
[3:56:16 PM] Drew Roos: but you can't, because uiVersion is always wrong in every form ever created
[3:56:36 PM] Drew Roos: so <data xmlns="..." formID="...">
[3:56:48 PM] Jonathan Jackson: yeah (see the sample xml)
[3:56:50 PM] Mitch Sundt: whatever you give me is what it is taged with...
[3:56:59 PM] Drew Roos: ok
[3:57:05 PM] Drew Roos: well formID is completely redundant
[3:57:13 PM] Clayton Sims: I'm way, way, way, pro on eliminating formid and using xmlns
[3:57:20 PM] Mitch Sundt: Form Id is either the xmlns attribute value or the value of the id attribute.
[3:57:39 PM] Drew Roos: <data xmlns="..." id="..."> ?
[3:57:48 PM] Matt Adams: @Clayton, same here.
[3:57:50 PM] Mitch Sundt: try running some forms through an xml validator sometime...
[3:57:59 PM] Ian Robert Lawrence: we use     <model>
      <instance>
        <data id="2rtoaucm">
[3:58:15 PM] Drew Roos: i'm fine with that
[3:58:47 PM] Mitch Sundt: exactly.  People like simple names, like "2rtoaucm" -- the XML spec requires xmlns be a URI (http://.../2rtoblah).
[3:59:28 PM] Mitch Sundt: Form id refers to either usage.  Use id="blah" or form up a big URI and go to town with xmlns
[4:00:44 PM] Anton de Winter: Mitch can you summarize what you'd like to see for a solution w.r.t the version+uiVersion issue
[4:01:08 PM] Drew Roos: for the record, the xml spec says relative URIs as namespaces are deprecated
[4:01:14 PM] Anton de Winter: Drew/Clayton can you do the same?
[4:02:03 PM | Edited 4:02:50 PM] Drew Roos: a single version attribute, format and meaning are undefined; servers make best-faith effort to process version #s intelligently; fine with id/xmlns "form id" scheme
[4:02:17 PM] Clayton Sims: xmlns as formid, single version attribute as integer
[4:02:49 PM | Edited 4:03:24 PM] Yaw Anokwa: alphanumeric thing as formId, single version attribute as incrementing integer. fine with using xmlns as form id as a stop gap, but i don't love it.
[4:03:02 PM] Matt Adams: I'm with Yaw on this.
[4:03:10 PM] Anton de Winter: What I'd imagine is that we have a simple version indicator made by humans for humans to easily keep track of changes in the form (any changes).  This version indicator shouldn't be relied upon for internal data merging by the server.  Something like the xmlns or formID (or a diff of some kind) should be used by the server to determine if relevant changes have happened.
[4:04:05 PM] Mitch Sundt: On the server, formId must match for the server to attempt ANY merge of data sets / form versions.
[4:04:23 PM] Jorn Klungsoyr: Hi, I may be completely off. But why would you restrict version to an integer?
Are you using the version number to communicate to the client the version number to use (that is always use the latest?).
[4:04:27 PM] Mitch Sundt: The version is metadata to track, as the form creator desires, the differences among tweaks to a form.
[4:04:35 PM] Mitch Sundt: This assumes uiVersion is eliminated.
[4:04:44 PM] Anton de Winter: yep
[4:05:43 PM] Mitch Sundt: Whether the server can handle model changes while the formID remains unchanges is server-specific.
[4:06:05 PM] Mitch Sundt: Aggregate, for example, can easily merge data for changes that don't alter the data model.
[4:07:12 PM] Jorn Klungsoyr: If the version is only used by the backend to handle things  - then there should be no reason to require it to be an integer.
[4:07:32 PM] Mitch Sundt: Why make it more complex?
[4:07:51 PM] Anton de Winter: Jorn, it won't only be used by the backend
[4:08:51 PM] Jorn Klungsoyr: But what would a client use it for? Other than being able to properly identify the version the data being submitted belongs to.
[4:08:58 PM] Mitch Sundt: And if you want the version to have more structure, the only thing that makes sense is the original uiVersion + version integers.
[4:09:47 PM] Mitch Sundt: and I think we've decided to keep it simple.
[4:09:48 PM] Anton de Winter: Jorn, in the case when an admin modifies the form and the user (on the client) needs to identify the form they want
[4:10:12 PM] Mitch Sundt: Yes, that is the other use case.
[4:10:39 PM] Mitch Sundt: If you pull the list of forms avaliable on the server, the version is presented and the client app can then know whether it has the same version.
[4:10:41 PM] Jorn Klungsoyr: But still, I don't see why that needs to be restricted to an integer. 
Any system should ensure that a version is unique - whether string or integer.
[4:11:43 PM] Anton de Winter: Well, I think string or arbitrary value isn't a great idea, because determining on the server side which is newer, which between "foo" and "bar" is newer?
[4:11:54 PM] Anton de Winter: constraining it makes life simpler for server implementors
[4:12:10 PM] Mitch Sundt: yes
[4:12:27 PM] Anton de Winter: Integer is simple, easy for a client with 0 software experience to also identify which is newer (the higher number)
[4:12:37 PM] Anton de Winter: 2.3.4.x could be confusing to someone with no software experience
[4:13:02 PM] Anton de Winter: and there appears to be little benefit to having x.x.x verus x
[4:13:09 PM] Anton de Winter: for our purposes, here.
[4:15:31 PM] Jorn Klungsoyr: Well, I think you also restrict which servers can act as backends.
If somebody has another versioning scheme, then it adds an extra unncessary level.
The backend can implement integer or string - or whatever - as long as it is possible to identify it.
[4:15:45 PM] Mitch Sundt: Note that a change to version/uiVersion in the Metadata schema would also be reflected in the FormListAPI, where the majorMinorVersion would just become a version (it was version + "." + uiVersion ).
[4:16:50 PM] Anton de Winter: Jorn, that's a fair point but it's also why we're pushing these APIs: if you comply with the API you agree what the versioning format should be
[4:17:08 PM] Anton de Winter: you know what to expect, as the server, and deal with it accordingly
[4:17:13 PM] Mitch Sundt: Integers can be stored as strings, but strings can't be stored as integers.  Restricting v1.0 to integers allows more servers to function, not less.
[4:17:15 PM] Anton de Winter: similarly your form creators need to follow that spec
[4:17:57 PM] Mitch Sundt: yes, it does restrict the form construction tools
[4:18:46 PM] Anton de Winter: but that's not a bad thing
[4:19:00 PM] Anton de Winter: (nor a hard thing to make work on the formdesigner side, honestly)
[4:19:20 PM] Mitch Sundt: it is easier to restrict now, and wait for demand to enlarge
[4:19:28 PM] Mitch Sundt: than to try to narrow later.
[4:19:31 PM] Anton de Winter: +1
[4:19:59 PM] Drew Roos: i don't care enough to continue this conversation
[4:20:15 PM] Mitch Sundt: I need lunch
[4:20:23 PM] Yaw Anokwa: i need a beer
[4:20:39 PM] Jorn Klungsoyr: If the spec just requires the version to be a unique string (at the API) level, then you don't restrict. Well I can say for openXdata this would be too restrictive.
[4:21:10 PM] Jonathan Jackson: lets go get beers, circle back in 30
[4:21:18 PM] Jonathan Jackson: no one leaves until we've accomplished our job.
[4:21:25 PM] Jorn Klungsoyr: I need to sleep, over and out |-)
[4:21:39 PM | Edited 4:21:46 PM] Cory Zue: i'm with jorn on this. Your server can limit the support if you want, but no reason to restrict it at the spec level
[4:22:21 PM] Drew Roos: my last comment: uiVersion had value, but the main failure was no one remembered to update it. if version was really "[version].[uiVersion]", that's good in that upgrading the 'content version' must reset the uiVersion
[4:23:02 PM] Drew Roos: so free-form version allows us the preserve the benefit of version/uiVersion without the faults