Thanks Mitch. I understand. It will be implemented as a custom extension
(in Enketo) using the http://enketo.org/xforms namespace.
···
On Wednesday, July 13, 2016 at 12:18:43 PM UTC-6, Mitch wrote:
>
> Note that in ODK Collect, in order to have the comment appear on the same
> page as the question, it is *required *that they both be wrapped in a
> begin group .. end group with "field-list" appearance.
>
> This is also crucial for enabling or disabling constraint checks on the
> questions, as *the constraints are enforced on forward swipe out of the
> page*. If the presence of a comment is to disable the constraint, then
> the comment field must be filled on the same page as the question or group
> of questions it should impact.
>
> This is central to the processing within ODK Collect and would not be
> changed.
>
> So any forms generator would need to wrap the question and comment in a
> group in order for ODK Collect to properly handle them.
>
> In that context, it seems like the orx:for attribute and comment
> appearance wouldn't provide much value-add within ODK Collect. Given how
> difficult it is to combine and re-structure the underlying Java views of
> questions to produce the "label" and "list-no-label" layouts, I don't
> envision anyone contributing an implementation to provide any visual
> support for this within ODK Collect.
>
> ----------
> I would have the the for attribute and comment appearance be Enketo
> extensions.
>
> But you need to think carefully about how to wrap these extensions in
> field-list groups if you want your forms to be usable on ODK Collect.
>
>
>
> On Tue, Jul 12, 2016 at 10:18 AM, Martijn van de Rijdt <mar...@enketo.org > wrote:
>
>> Thanks Chris,
>>
>> Thinking some more about form-wide global comment requirement, I think it
>> would be elegantly covered like this (where "data" is the root node in the
>> primary instance) without groups:
>>
>>
>>
>> But indeed for global comments (only), you wouldn't necessarily need the
>> "for" attribute. Using it you'll be able to extend it further in the future
>> though, in case users ever want question- or group-level comments. Some
>> Enketo and SMAP users already have this requirement, so it seems possible
>> that might happen.
>>
>> Anyway, no problem to make it an enketo-specific extension either. Will
>> wait a few days in case Yaw, Mitch, you, and others, have additional input
>> and otherwise proceed.
>>
>> Cheers,
>> Martijn
>>
>> On Tuesday, July 12, 2016 at 10:09:23 AM UTC-6, Christopher Robert wrote:
>>>
>>> Hi Martijn,
>>>
>>> Thanks for always getting input -- even when it means you'll get random
>>> and differing opinions!
>>>
>>> Even if this became part of the spec, I don't honestly think that we'd
>>> spend the time to integrate or document it in SurveyCTO. We just have about
>>> 600 higher priorities from users, and our desire to support commenting was
>>> more or less addressed by our form-wide comment facility long ago.
>>>
>>> While I agree in principle with the idea that comments should be better
>>> supported in-spec, we'd still push for something simpler and form-wide,
>>> just because we've gotten consistent positive or neutral feedback on that
>>> (never had anybody want group-by-group or field-by-field that I can
>>> remember). But that's just my opinion based on our interactions with
>>> SurveyCTO users.
>>>
>>> Best,
>>>
>>> Chris
>>>
>>> On Tue, Jul 12, 2016 at 11:44 AM Martijn van de Rijdt wrote:
>>>
>>>> Mitch, Yaw, Chris,
>>>>
>>>> I wanted to see if we can come to a conclusion on whether the "for"
>>>> attribute should become part of the OpenRosa/ODK XForm spec. If you like
>>>> the approach and think you may want to leverage this in a future version of
>>>> ODK Collect, I'd say let's do it. Otherwise, we'll just treat this as a
>>>> custom Enketo extension, use a different namespace and document it
>>>> elsewhere. I'd be happy to discuss further as well of course.
>>>>
>>>> Thanks,
>>>> Martijn
>>>>
>>>> On Monday, June 27, 2016 at 9:52:11 AM UTC-6, Martijn van de Rijdt wrote:
>>>>>
>>>>> I much appreciate your comments, Chris.
>>>>>
>>>>> For comments on several questions, this method would facilitate that
>>>>> by pointing the "for" attribute to a group. It is one of the future
>>>>> requirements we had in mind as well when designing this. So your past
>>>>> requirement for one comment field for the whole form, could be met by
>>>>> placing all questions in a group, and then creating a single comment
>>>>> question that points to it. In that case, we may want to add flexibility
>>>>> for positioning the comment button (e.g. with top, bottom appearances).
>>>>>
>>>>> I agree with the laboriousness for per-question comments. The idea is
>>>>> that this is only really workable for form-builders where you would just
>>>>> tick a box and that would generate the XLSForm or XForm output
>>>>> automatically.
>>>>>
>>>>> Yes, bypassing-validation with regular constraint and required XPath
>>>>> expressions was really a key advantage that made us decide to go for this
>>>>> approach, despite the laboriousness of hand-coding individual question
>>>>> comments (in XForm or XLSForm).
>>>>>
>>>>> Cheers,
>>>>> Martijn
>>>>>
>>>>> On Sat, Jun 25, 2016 at 12:10 AM, Christopher Robert < cro...@surveycto.com> wrote:
>>>>>
>>>>>> Okay, thanks! That helps.
>>>>>>
>>>>>> It's still a bit unclear to me whether appearance+for is ideal vs.
>>>>>> some other way of specifying both the functionality desired and the
>>>>>> link(s). For example, if you wanted a comment on a set of questions rather
>>>>>> than just one, how would that happen? Using "for", you might get locked
>>>>>> into a 1-to-1 design that turns out to be less than ideal for comment
>>>>>> facilities.
>>>>>>
>>>>>> As a point of reference (and, I realize, general irritation), we
>>>>>> added comment capability into SurveyCTO some years back. And we did it by
>>>>>> adding a new field type that would accept comments form-wide. So,
>>>>>> essentially, if you added a "comments" field to your form, then a
>>>>>> context-menu option to add a comment would be available survey-wide, and
>>>>>> the comments field would end up holding a .csv file with comments linked to
>>>>>> the fields with which they were associated. So, you might get no .csv file,
>>>>>> a .csv file with a single comment for a single field, or a .csv file with
>>>>>> potentially lots of comments. These comments were held separately from the
>>>>>> core form data, in separate (but attached) .csv files so that you could
>>>>>> import and manage them separately from your core analysis. It was ad-hoc
>>>>>> and designed to meet some users' needs, though certainly imperfectly.
>>>>>> Client UI's could differ in how they allowed addition of comments, but we
>>>>>> used the same basic approach in both our Android and web UI's (a context
>>>>>> menu).
>>>>>>
>>>>>> In my view, most users who want to accept comments likely want to
>>>>>> accept them either everywhere or at least in most places -- so having to
>>>>>> code comment fields separately, field-by-field, would be tremendously
>>>>>> laborious to the point of not being useful. That's just my opinion, though,
>>>>>> and obviously you have at least one client willing to pay for the
>>>>>> field-by-field option.
>>>>>>
>>>>>> It also seems quite dangerous to allow any kind of blanket bypassing
>>>>>> of validation, so your approach to that (allowing them to code this into
>>>>>> the validation itself) seems like a really smart one. In a great many
>>>>>> cases, forms are designed such that people reasonably expect -- perhaps
>>>>>> within the logic and UI of the form itself, but certainly in the back-end
>>>>>> processing and analysis -- that required fields will be required and that
>>>>>> constraints will be enforced. Once you start allowing people to escape
>>>>>> validation, the design, testing, and analysis tasks become just so much
>>>>>> more complex. While we do have users who occasionally ask for
>>>>>> blanket-validation-escape options, we generally talk them out of it. And we
>>>>>> haven't been willing to build such things into SurveyCTO, believing that
>>>>>> even those who request it would be poorly served by the consequences.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> On Fri, Jun 24, 2016 at 11:36 AM Martijn van de Rijdt < mar...@enketo.org> wrote:
>>>>>>
>>>>>>> Thanks Chris,
>>>>>>>
>>>>>>> The use case that prompted this change was the desire to comment on
>>>>>>> questions (similar to what SMAP server is doing on their ODK Collect fork -
>>>>>>> but without the limitation it has beyond their use case) and enter those
>>>>>>> comments by clicking a button next to the question that would reveal some
>>>>>>> kind of modal. In addition, the presence or value of a comment would have
>>>>>>> to allow bypassing validation. E.g. question A is required, unless there is
>>>>>>> a comment on that question. So eventually after going through many complex
>>>>>>> options, we can back to the idea that those comment questions should be
>>>>>>> coded into the XForm like any other question. Any validation logic can thus
>>>>>>> be coded normally with XPath. The additional benefit is that labels,
>>>>>>> translations, hints, etc. are also completely flexible and don't have to be
>>>>>>> hardcoded. I should also note that the client that has paid for this, will
>>>>>>> have different types of 'comment' questions and one question could even
>>>>>>> have multiple comment types. This is far beyond the scope of this proposal,
>>>>>>> but it played a role in coming up with this implementation.
>>>>>>>
>>>>>>> So to do this, we could use the "for" attribute to *visually* link
>>>>>>> from the comment question to the question it links with. Any logic
>>>>>>> (relevant, constraint) links are separate from that.
>>>>>>>
>>>>>>> A client, such as Enketo or ODK Collect, would require only one more
>>>>>>> XForm addition to respond to the use case described above, which is a new
>>>>>>> appearance. The one I wanted to propose, if we make the "for" attribute an
>>>>>>> official OpenRosa feature, is to use appearance="comment".
>>>>>>>
>>>>>>> A second (optional) additional proposal would be to link the
>>>>>>> question node in the model with the comment node(s) (note the link goes in
>>>>>>> a different direction here). The objective would be to facilitate the
>>>>>>> presentation of submitted data on the OpenRosa server for easy analysis
>>>>>>> without having to evaluate the XPath expressions in "for" attributes in the
>>>>>>> XForm binds. That addition would not be required or used by Enketo or ODK
>>>>>>> Collect. It's purely for the server. Let me know if you want me to
>>>>>>> elaborate further on this already.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martijn
>>>>>>>
>>>>>>>
>>>>>>> On Thursday, June 23, 2016 at 11:12:51 AM UTC-6, Christopher Robert wrote:
>>>>>>>
>>>>>>>> Hi Martijn,
>>>>>>>>
>>>>>>>> Sounds interesting. Can you say any more about the likely use cases
>>>>>>>> and the additional specification extensions those might require?
>>>>>>>>
>>>>>>>> I ask only because it seems a bit difficult to think about this
>>>>>>>> "linking of questions" issue separated from the nature of the links
>>>>>>>> themselves -- and what other properties or parameters would be required to
>>>>>>>> support those types of links. For example, you might say that when field q3
>>>>>>>> has a relevance expression like "q1+q2 < 100", then q3 is linked in a way
>>>>>>>> with q1 and q2: its visibility depends on q1 and q2. Likewise, constraints
>>>>>>>> can include links, labels can include links, and so we have varied ways in
>>>>>>>> which fields are already related to one another. And in a sense you can say
>>>>>>>> that all of the fields within a group (with the field-list appearance or
>>>>>>>> otherwise) are related.
>>>>>>>>
>>>>>>>> In none of those cases is a separate "for" construct necessary, and
>>>>>>>> so it gets me thinking about what other kinds of links might or might not
>>>>>>>> require (or benefit from) a "for" linkage. That's why I thought more use
>>>>>>>> cases might be useful, to determine whether they share the need for a new
>>>>>>>> "for"-type linkage, or if, like the existing linkages, they might be
>>>>>>>> somehow implicit or arranged in some other way. For example, if another
>>>>>>>> extension might be necessary to support modal pop-ups, then might that
>>>>>>>> extension itself not have its own way of specifying the linkages?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jun 23, 2016 at 12:57 PM Martijn van de Rijdt < mar...@enketo.org> wrote:
>>>>>>>>
>>>>>>>>> Hi ODK Devs,
>>>>>>>>>
>>>>>>>>> We added some functionality to Enketo and wanted to propose a
>>>>>>>>> related addition to the OpenRosa/ODK XForm specification.
>>>>>>>>>
>>>>>>>>> If you agree with this addition to the XForms spec (or an
>>>>>>>>> alternative), I'll add it to the documentation and use the OpenRosa
>>>>>>>>> namespace. If, not we'll just consider it an Enketo-specific extension and
>>>>>>>>> use an Enketo namespace. In either case the XForms are functional in ODK
>>>>>>>>> Collect, because the addition is just ignored.
>>>>>>>>>
>>>>>>>>> *Requirement:*
>>>>>>>>>
>>>>>>>>> Visually link two questions together. Can be used for various
>>>>>>>>> features, e.g. one question could be a comment on another question.
>>>>>>>>>
>>>>>>>>> *Proposal*:
>>>>>>>>>
>>>>>>>>> Add a namespaced `for"bind attribute, like this:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The `for` attribute contains a relative or absolute path to the
>>>>>>>>> question it links with. So in combination with an appearance you could now
>>>>>>>>> visually link these questions together in creative ways that regular XForm
>>>>>>>>> groups do not allow. E.g. add a button to the linked question that when
>>>>>>>>> clicked shows a modal containing the other question. There are no
>>>>>>>>> restrictions, special assumptions or magic. A question could have multiple
>>>>>>>>> questions linked to it for example.
>>>>>>>>>
>>>>>>>>> If there is some enthusiasm for this I'll follow up with another
>>>>>>>>> more specific proposal to build upon this XForm addition to create a very
>>>>>>>>> flexible comment feature.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Martijn
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Revolutionizing data collection since 2012.*
>>>>>>>>>
>>>>>>>>> Enketo | LinkedIn
>>>>>>>>> | GitHub
>>>>>>>>> | Twitter
>>>>>>>>> | Blog
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "ODK Developers" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to
>>>>>>>>> opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> *Revolutionizing data collection since 2012.*
>>>>>>>
>>>>>>> Enketo | LinkedIn
>>>>>>> | GitHub
>>>>>>> | Twitter
>>>>>>> | Blog
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "ODK Developers" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to opendatakit-developers+unsubscribe@googlegroups.com
>>>>>>> .
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to a topic in
>>>>>> the Google Groups "ODK Developers" group.
>>>>>> To unsubscribe from this topic, visit
>>>>>> https://groups.google.com/d/topic/opendatakit-developers/SaNMPr9eSyQ/unsubscribe
>>>>>> .
>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>> opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Revolutionizing data collection since 2012.*
>>>>>
>>>>> Enketo | LinkedIn
>>>>> | GitHub
>>>>> | Twitter
>>>>> | Blog
>>>>>
>>>>
>>>> --
>>>> *Revolutionizing data collection since 2012.*
>>>>
>>>> Enketo | LinkedIn
>>>> | GitHub
>>>> | Twitter
>>>> | Blog
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ODK Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>> --
>> *Revolutionizing data collection since 2012.*
>>
>> Enketo | LinkedIn
>> | GitHub
>> | Twitter
>> | Blog
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ODK Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to opendatakit-developers+unsubscribe@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Mitch Sundt
> Software Engineer
> University of Washington
> mitche...@gmail.com
>