Time |
Nick |
Message |
00:04 |
|
jvwoolf joined #evergreen |
00:27 |
|
yar joined #evergreen |
08:02 |
|
collum joined #evergreen |
08:06 |
|
Dyrcona joined #evergreen |
08:18 |
|
Stompro joined #evergreen |
08:31 |
|
mmorgan joined #evergreen |
08:34 |
|
dbwells_ joined #evergreen |
09:05 |
Bmagic |
I need to figure this xpath stuff out. metabib_field - I need to glue two subfields together and then join the rest with dashes. Such that the browse index looks like this 600a{space}600b{ -- }600[cdfgklnpstuvxyz] |
09:06 |
Bmagic |
I've tried xpath = //marc:datafield[@tag='600' and @ind2='0']. browse_xpath = "//*[contains("adlfmnoprsvxyz",@code)]" |
09:19 |
Dyrcona |
Not sure you can join text like that in xpath itself. |
09:23 |
Bmagic |
hmmm |
09:24 |
Bmagic |
It seems so close |
09:31 |
Dyrcona |
Maybe you want XSLT? |
09:32 |
Bmagic |
I'm open to anything |
09:34 |
Dyrcona |
Bmagic: You're trying to do this in crad or something like that, yeah? |
09:38 |
Dyrcona |
And this, { -- }600[cdfgklnpstuvxyz], means you want the other subfields, if any joined after the rest by dashes? Such that 600 $a Bob $b Marley $c Wailers $d Bunny Wailer $f Peter Tosh would like "Bob Marley - Wailers - Bunny Wailer - Peter Tosh"? |
09:38 |
Bmagic |
yep |
09:39 |
Dyrcona |
I thinks that's easier with xslt, but you can't use xslt with crad. |
09:40 |
Bmagic |
what's crad? |
09:40 |
Bmagic |
I'm working in the config.metabib_field table - reingesting a test record and then seeing what indexes were created |
09:41 |
Dyrcona |
config.record_attr_definition |
09:42 |
Bmagic |
oh - that is a different issue that I've put on hold |
09:42 |
Dyrcona |
You can probably do it there with a joiner, but you can't have two joiners. |
09:42 |
Dyrcona |
Either space or -. |
09:44 |
Bmagic |
alright - thems the breaks I guess |
09:44 |
Dyrcona |
We have a Genre entry. |
09:46 |
Dyrcona |
Put his in xpath: //marc:datafield[@tag='600'] |
09:47 |
Dyrcona |
Put this in browse_xpath and display_xpath: //*[local-name()='subfield' and contains('abcdfgklnpstuvxyz',@code)] |
09:48 |
Dyrcona |
Then whatever you want for the joiner, I'd recommend '-- '. NOTE the space after --. |
09:48 |
Dyrcona |
Try that see if it's close. |
09:48 |
Bmagic |
alright - checking it out |
09:50 |
Bmagic |
comes out like this: "-- Wesley, John, -- -- 1703-1791 -- -- Bibliography. --" |
09:51 |
Bmagic |
which I've got before exactly like that. using various permutations |
09:52 |
Bmagic |
oh but it created two indexes. the other one looks like this: "Wesley, John, 1703-1791." |
09:53 |
Bmagic |
and this is the marc =600 10$aWesley, John,$d1703-1791$vBibliography. |
09:55 |
Bmagic |
there is another 600 entry. Probably the reason why there are two indexes created from the same definition: =600 17$aWesley, John,$d1703-1791.$2fast$0(OCoLC)fst00036627 |
09:59 |
Dyrcona |
Well, yeah. Each 600 field will get processed. |
09:59 |
Bmagic |
removing the second 600 for now - leaves me with just one index from your recommended settings. The index that is preceeded with the double dash |
09:59 |
Dyrcona |
It has been a few years since I messed with this stuff much, so I'm a bit rusty. |
10:03 |
Bmagic |
all of the other marcxml index definitions that have joiners are using a " " space. So I wonder if those are also resulting in a preceeding space but it's not noticable |
10:07 |
Bmagic |
well now I am really confused - I updated the index to have a joiner space ' ', reingested the test record. And I still get "-- Wesley, John, -- -- 1703-1791 -- -- Bibliography. --" lol |
10:08 |
Bmagic |
I'm betting that the new definition wasn't different enough for it to recalculate |
10:09 |
Dyrcona |
Browsers generally compress multiple spaces into 1. |
10:10 |
Bmagic |
but why is it putting in the dashes when the joiner is a space? |
10:10 |
Dyrcona |
Um, no. Ingest isn't that smrt. |
10:11 |
Dyrcona |
smart. It will use what's in the field. Where are you seeing the dashes? |
10:11 |
Bmagic |
I've just confirmed that it's definitely doing that. I deleted the 600 field from the marc, save it , then put it back. and the dash index is back pointing to my 1003 ID number definition which does NOT have a joiner = ' -- ' |
10:13 |
Dyrcona |
Where are you seeing the dashes? In the OPAC? In the database? If so, what field of what table? And, browse may add --, cause that's "expected" for browse.... |
10:13 |
Dyrcona |
But, miker would know more about this than I. |
10:13 |
Bmagic |
database |
10:14 |
Bmagic |
select * from metabib.browse_entry mbe, metabib.browse_entry_def_map mbedm where mbe.id=mbedm.entry and mbedm.source = 541257 |
10:16 |
Bmagic |
now I've got the joiner set to null and it's still putting in the dashes. Is it possible that the index is combined somehow with another index that might be overlapping some of the same tag/subfields? |
10:16 |
Dyrcona |
Try this: SELECT metabib.reingest_metabib_field_entries(bib_id := 541257); |
10:17 |
Bmagic |
pretty much the query I am using |
10:17 |
mmorgan |
Bmagic: can you share the whole row from config.metabib_field_entry? |
10:17 |
Bmagic |
sure |
10:19 |
pastebot |
"Bmagic" at 168.25.130.30 pasted "Current xpath subject browse index" (5 lines) at http://paste.evergreen-ils.org/10139 |
10:19 |
Bmagic |
it's been changed so many times, but here is the current state |
10:24 |
Dyrcona |
You xpath is broken. |
10:24 |
Dyrcona |
fingers-- |
10:25 |
Bmagic |
oh! where? |
10:25 |
* miker |
looks up |
10:25 |
Dyrcona |
Oh no, never mind. xpath syntax sucks. |
10:25 |
Bmagic |
xpath_syntax-- |
10:26 |
Dyrcona |
I think you should remove this from the xpatch field: and marc:subfield[@code="a"] and marc:subfield[@code="d"] |
10:26 |
Bmagic |
I threw that in there later. It was* identical to your suggestion above |
10:27 |
miker |
if you have a special-purpose cmf there's no reason you couldn't create an xslt to do something special |
10:28 |
Bmagic |
It sounds like we can't get subfield a+b and the rest of them joined with dashes - which is probably ok. At this point, I am trying to figure out why the index STILL has dahses with joiner set to null |
10:28 |
miker |
if you can create a stylesheet that xsltproc can use to transform a marcxml record (in a file) into something with the contents you want, then you can just stick that in config.xml_transform and use it in cmf |
10:28 |
Dyrcona |
miker++ |
10:29 |
miker |
Bmagic: you can't in xpath alone, but you can with a wee bit of xslt |
10:29 |
Bmagic |
Alright, that sounds good. And rather than editing the existing templates, you're saying I should make a new one... and hook that up down the tree |
10:30 |
miker |
yeah, no reason to have to maintain a special change to, say, the mods32 stylesheet |
10:30 |
Bmagic |
sounds like the correct solution - I'm still confused on this dash thing. I guess it's time to just delete it |
10:31 |
miker |
browse entries do not get deleted once added, but the map to the source bib should be removed unless you have flags turning off browse ingest or something |
10:31 |
Bmagic |
putting malformed xslt in the database will probably be a bad thing, so it makes me slightly nervous. |
10:32 |
miker |
it would do bad things. but that's why you test with xsltproc at the command line :) |
10:32 |
Bmagic |
ah! - so the index that I see is leftover from a previous definition. And the new definition isn't matching (or something) - and therefore the engine doesn't re-process the index, leaving the old one there |
10:33 |
Bmagic |
well no, I tested that theory by deleting the 600 from the marc, saw that the index was also removed from metabib.browse_entry. Then put the tag back, and the friggin dashed index came back... pointing to my definition with a null joiner |
10:35 |
Dyrcona |
Bmagic: you may already have something processing the 600 tag, and your addition was not matching because of the extra stuff in the xpath field. |
10:35 |
Dyrcona |
I suggest select id, xpath from config.metabib_field; |
10:36 |
mmorgan |
But the metabib.browse_entry was pointing to definition 1003 ... |
10:36 |
Bmagic |
I could buy that if it weren't for the fact that the index in metabib.browse_entry_def_map pointed def -> my ID (1003) |
10:37 |
Bmagic |
mmorgan++ |
10:37 |
Dyrcona |
OK. |
10:37 |
Bmagic |
so, I think, I'm abandoning ship on this. No clue why the system would put in dashes when joiner is null. But, moving on to xslt |
10:42 |
Bmagic |
miker: to save time, I am looking at some examples from config.xml_transform - specifically the mods33 template. |
10:45 |
miker |
Bmagic: you might want to consider looking at the marc880 transform as well. all the mods stylesheets are .... huge ... and embed a pile of helper templates that I don't think are in the 880 one |
10:46 |
Bmagic |
not seeing that one in config.xml_transform |
10:46 |
Bmagic |
perhaps it's in Evergreen source somewhere |
10:46 |
Bmagic |
or online... |
10:47 |
miker |
marc21expand880 |
10:47 |
Bmagic |
oh, now that one is there.. lol |
10:54 |
Dyrcona |
Here's to the junky, funky git branches full of experiments and revert commits! |
10:54 |
Dyrcona |
@swill |
10:54 |
* pinesol |
grabs a can of Sparks Light and sends it sliding down the bar to Dyrcona |
11:00 |
Dyrcona |
mutlitasking-- |
11:00 |
Dyrcona |
or multitasking, take your pick. :) |
11:04 |
* mmorgan |
is not a fan of multitasking. Start many projects, finish none. |
11:04 |
Bmagic |
miker: when testing with xsltproc - can I just copy/paste the marc xml into a file and pass that in the second argument? |
11:05 |
miker |
Bmagic: that should work |
11:05 |
Bmagic |
wrapped in <collection> ? |
11:09 |
Bmagic |
I just ran the raw 880 template against the marc xml - seemed to work, though I'm not sure what to expect. It seemed to simply dump the xml back out |
11:35 |
|
sandbergja joined #evergreen |
11:38 |
Dyrcona |
fingers-- typos-- |
11:58 |
|
sandbergja joined #evergreen |
11:59 |
|
mrisher joined #evergreen |
12:03 |
Dyrcona |
Hmm... Gotten 83 Returning NULL after request time out this morning..... |
12:08 |
|
khuckins joined #evergreen |
12:42 |
pastebot |
"Bmagic" at 168.25.130.30 pasted "XSLT First draft for 600a+d plus double dash the rest" (42 lines) at http://paste.evergreen-ils.org/10140 |
12:42 |
Bmagic |
miker: it seems like it's transforming it the way I want |
12:46 |
Bmagic |
Further "glue" can take place in config.metabib_field with joiner. Something like xpath=$$//marc:datafield[@tag="subject-browse-600ad" and @ind2='0']$$ browse_xpath=$$//*[contains("abcdfgklnpstuvxyz",@code)]$$ joiner=' -- ' |
12:46 |
Bmagic |
or, were you thinking that the whole thing would be handled in xslt? |
12:47 |
miker |
cool. then the cfm can just look for (untested) //marc:datafield[@tag="subject-browse-600ad"]/marc:subfield (and maybe some subfield predicate) and use a joiner of ' - ' or whatever. but you /might/ not want to use a long @code ... just using 'a' (and discarding 'd') might be simpler |
12:48 |
miker |
meh, either way |
12:48 |
miker |
(you may want to namespace the <subfield> elements, too, though) |
12:49 |
miker |
with xml, always be explicit about your namespaces if you can. default namespace assumptions will only cause pain down the road |
12:50 |
Bmagic |
the manipulated subfields come out with xmlns="" - the rest of the marc record subfields do not mention xmlns |
12:51 |
miker |
I know... that's what I'm saying. xmlns="" is not the same as the default ns, which is the explicitly named marc ns |
12:52 |
Bmagic |
inject this into the subfield loop? |
12:52 |
miker |
if you just put marc: in front of subfield in the element open and close, you'll save yourself some trouble |
12:52 |
Bmagic |
<xsl:attribute name="xmlns"><xsl:value-of select="http://www.loc.gov/MARC21/slim" /></xsl:attribute> |
12:53 |
Bmagic |
oh, ok |
12:53 |
miker |
no, just like the datafield element |
12:53 |
miker |
but /don't/ try to do anything to attributes... xml ns rules are complicated |
12:55 |
miker |
attributes are allowed to not have a namespace, and they do /not/ live in the default namespace |
12:55 |
Bmagic |
cool - that took care of that empty value for xmlns |
12:55 |
Bmagic |
miker++ #xslt wisdom |
13:10 |
Bmagic |
once in the database, the parser throws a fit about "XML declaration allowed only at the start of the document" |
13:11 |
Bmagic |
maybe just remove the top line of my template |
13:12 |
Bmagic |
yep |
13:12 |
Bmagic |
fixed it |
13:13 |
Bmagic |
results: "-- Wesley, John, 1703-1791 -- -- Bibliography. --" |
13:13 |
Bmagic |
soooo close. It glued a+d and double dashed the rest! |
14:09 |
Bmagic |
Changed the xslt to handle everything. Got rid of the joiner and we have success |
14:09 |
Bmagic |
Dyrcona++ miker++ mmorgan++ # thanks for putting up with me |
14:10 |
mmorgan |
Bmagic++ |
14:10 |
mmorgan |
success++ |
14:10 |
Bmagic |
:) |
15:58 |
|
sandbergja joined #evergreen |
17:09 |
|
mmorgan left #evergreen |