On Thu, Jun 7, 2012 at 10:08 AM, Frank Bennett <[email protected]> wrote: > On Thu, Jun 7, 2012 at 10:13 PM, Bruce D'Arcus <[email protected]> wrote:
... >> I guess I just need think if we're going to go this way, we better >> define the model (is a point locator a single value, or is it a list >> of key-values) so that it's clear, and that we probably shouldn't be >> changing it later. Just emphasizing here this is my key point. But ... ... > There were a number of tricky issues, but one of the most difficult > was working out how an actual, user-supplied locator field and label > should interact with the leading, structured portion supplied via the > "section" field. For example, suppose an entry for 23 USC 253(a), > where the section field is set as "sec. 253(a)". Now suppose this > provision is cited at 253(a)(i), with "(i)" supplied via the user > locator. Alternatively, suppose it is cited at 23 USC 253(a) para. 2, > where the "para." element might come from the pull-down menu, or be > supplied as an abbreviated term at the start of the locator field. > > There are also problems with multiple locators, such as "23 USC 253(a) & 264". Right. While I don't understand all the intricacies of your case, the point is my suggestion here does not mean these fields are free text; they are comma-separated lists of structured key values, where optionally a key is empty and its value is free text. So users would have to account for that presumably. I can't imagine any other way. > I was able to make things work pretty well (i think), but the > experience suggested to me that mixing two structures in input > (pull-down labels for the initial element, possibly overridden by a > leading in-field label like "sec.", and embedded in-field labels for > the rest) was a headache. It will be easier to just use embedded > in-field label abbreviations for everywhere and dispense with the > pull-down label altogether in the UI. OK. Sounds like we agree. > The use case shown above (with > "&") also shows that a strict key/value representation will be too > limiting. But that presumes we all accept the requirement that users should be able to do that. I don't (but my opinion is just one). > We need to localize the label to the style (so "sec." or > "section" in some styles, and a section symbol in others), but > preserve user-supplied connecting punctuation. Given this is the key problem now in moving forward with a concrete proposal, can you expand on why you say this is a requirement? Consider how Zotero deals with dates; why not something like that here? Bruce > It's a messy > half-structure, but that's how things are referenced, and I concluded > that there isn't much that can be done for further discipline. > > Frank > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
