Timestamps are in GMT/BST.
[4:15] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[4:33] * eddies (~eddies@bb220-255-224-197.singnet.com.sg) has joined #duraspace
[4:33] * eddies (~eddies@bb220-255-224-197.singnet.com.sg) Quit (Changing host)
[4:33] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[4:57] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[6:53] -cameron.freenode.net- *** Looking up your hostname...
[6:53] -cameron.freenode.net- *** Checking Ident
[6:53] -cameron.freenode.net- *** Found your hostname
[6:53] -cameron.freenode.net- *** No Ident response
[6:53] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:53] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:53] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:14] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:31] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[14:11] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[14:11] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[14:11] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[17:34] * barmintor (~ba2213@dyn-butler-158-112.dyn.columbia.edu) has joined #duraspace
[17:34] <eddies> can't promise i'll be very alert
[17:35] <barmintor> eddies: just sent an email, but basically the datastreamsProfiles.xsd was the best attempt I had to:
[17:35] <barmintor> 1) keep backwards compatibility
[17:35] <barmintor> 2) use common generated classes for serialization
[17:35] <barmintor> 3) be validatable
[17:36] <barmintor> but I'm not committed to that implementation, if you have an idea of how to improve it
[17:37] <barmintor> also, can't remember if we discussed this on the comm. call, but I added a REST resource for schemas
[17:37] <barmintor> so docs have schemaLocations that point back to the repo now
[17:37] <eddies> actually, i wasn't sure (not having tested yet) if the changes were backwards-compatible, so that's good to know, as it was one of the things i was worried about
[17:38] <barmintor> I'm pretty sure they are (unless you use the old schema and ask for profiles)
[17:38] <eddies> the schema change i mentioned was just a tweak that seemed to follow what we were doing in some of our other schemas
[17:39] <barmintor> yeah- I *think* I actually tried that, and had some trouble getting it to work
[17:39] <eddies> and it made the classes i was generating in fedora-client not require a separate binding instructions file
[17:40] <eddies> (otherwise i was getting DatastreamProfileType classes instead of DatastreamProfile classes)…trivial binding file
[17:40] <barmintor> Hmm
[17:40] <eddies> so it's not a big deal
[17:41] <eddies> sec. brb
[17:41] <eddies> back
[17:41] <eddies> so i didn't test the schema change i proposed on fcrepo. just in fedora-client
[17:42] <eddies> but at least there, the generated classes seem fine
[17:42] <barmintor> If the integration tests pass, I'm inclined to not worry
[17:43] * barmintor mutters under his breath about OM
[17:44] <eddies> i'm happy to go w/ the binding file…it's just that it feels like there's inconsistency with ObjectDatastreamsType/ObjectDatastreams, ObjectMethodsType/ObjectMethods (and other perhaps?)
[17:44] <barmintor> I really have no preference for the way I did it, as long as it doesn't result in have to to type checking on the server side
[17:45] <eddies> also, is it "ok" that our schema locations are local, relative references?
[17:45] <eddies> e.g. schemaLocation="blah.xsd"
[17:46] <barmintor> why wouldn't it be?
[17:46] <barmintor> (that's not sarcastic)
[17:47] <eddies> well, for a client that's getting the schemaLocation in a response, that doesn't help much for dereferencing
[17:47] <eddies> just wondering. perhaps not clearly
[17:47] <barmintor> doesn't the client have the url for the resource it just requested?
[17:48] <barmintor> I actualy thought it was building the full url to the schema, fwiw
[17:48] <barmintor> oh, is it because it's ambiguous to a client? (file system or relative url)
[17:48] <eddies> so, client requests: http://example.com/fedora/objects/demo:123/datastreams?profiles=true, response contains "schemaLocation=datastreamProfile.xsd"
[17:48] <kompewter> [ IANA — Example domains ] - http://example.com/fedora/objects/demo:123/datastreams?profiles=true,
[17:49] <eddies> ack, i'm being spacey
[17:49] <eddies> nm. i actually can't remember what's in that particular client response as far as schema location goes
[17:50] <eddies> i think the serializer is constructing it correctly
[17:53] <eddies> ok. well, i'm turning in. i'm going to test parsing responses with the new schema generated classes against fedora 3.5. if that works, then i'm happy
[17:53] <eddies> (tomorrow, that is)
[17:53] <barmintor> ok, sorry to keep you up
[17:53] <eddies> no worries
[17:53] <barmintor> sleep well!
[17:53] <eddies> danke
[17:54] * barmintor (~ba2213@dyn-butler-158-112.dyn.columbia.edu) has left #duraspace
[21:07] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:51] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:52] * scottatm (~scottatm@adhcp218.evans.tamu.edu) Quit (*.net *.split)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.