apologies for this---misrouted email to dfh.
David Karger wrote:
> it's looking pretty good; certainly is generting the cat field
> properly. A couple of notes:
> * export generated html output is missing. That is necessary to create
> googlable pages.
> * it looks like some characters are being transofrmed incorrectly. Note
> the question marks in potluck abstract, which i think should be dashes
> * will the converter properly handle quotation marks inside a field? ie
> if I say in bibtex
> abstract={This is a "good" paper}
> what will happen to the json?
> * you've generated a proper accent mark on the e in Medard in the
> content, but in the author facet it shows Medard with accent but also
> M\'edard, and also shows M<gibberish>dard. but then you have proper
> accents for laszlo lovasz. strange.
> * I wonder if babel should generate a "bibtex:" attribute that stores
> the raw bibtex associated with each the json record. this would give
> you full-fidelity export of bibtex. Some work to deal with the bibtex
> "crossref" attribute, but still, might be easiest overall. Because then
> you could safely zap various tex things from the converted fields.
> * I got surprised by the facet behavior, though i can now see a
> justification for it: clicking on a value selected that value _only_.
> to get multiple values I had to careful hit the checkboxes. Is that
> intentional?
> * I got tripped up by the "copy raw data button"---didn't expect it to
> output everything, only the stuff I had currently selected.
> * the converter messed up on the name "Douglass S. J. {De Couto}" (look
> under C in the author facet). tex uses the braces to say "this person
> has a two word last name". I have to ask Max Van Kleek if his name is
> wrong too.
> * You'll note i am both David Karger and David R. Karger (you have two
> names too). It would be nice if there were a way to "merge" these two
> things in the author facet. I guess one approach is to create a "name"
> type, and the give each name a "person" property, such that two names
> for the same person have the same person property, and then "group by
> person", but this seems like overkill, doesn't it?
>
>
>
>
> Daniel B. Giffin wrote:
>
>> in the display of an item, i'd like some of the items that occur as
>> its property values to be rendered "inline" (directly in the page)
>> instead of as popups.
>>
>> (there was an earlier thread under the subject "Exhibit Handling
>> Hierarchical JSON Data", and this could be one way to show some more
>> of the graph's depth.)
>>
>> i think inline rendering could be specified in a lens by adding an
>> attribute like "ex:inline" to an element that uses ex:content.
>>
>> for example:
>>
>> <div ex:role="lens" class="nobelist">
>> ...
>> <span ex:content=".co-winner" ex:inline="true">
>>
>> this would mean that the .co-winner property values should be rendered
>> inline here.
>>
>> of course, there's some danger of writing recursive lenses that go on
>> rendering dom nodes until your browser explodes. (i think my example
>> would do that.) but i don't think that's a reason not to provide the
>> facility.
>>
>> thoughts?
>>
>> (i might have a go at implementing this myself. i'm eyeing
>> Exhibit.Lens.prototype._constructDefaultUI(). it seems like it could
>> be straightforward, although it looks like there are some subtleties
>> concerning rendering an item more than once, and perhaps other stuff i
>> haven't thought of.)
>> _______________________________________________
>> General mailing list
>> [email protected]
>> http://simile.mit.edu/mailman/listinfo/general
>>
>>
> _______________________________________________
> General mailing list
> [email protected]
> http://simile.mit.edu/mailman/listinfo/general
>
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
