00:07:34 re. canonicalized form, doing the "unmoding" is what does that. 00:09:22 @mode is logically equivalent to MIME Content-Encoding. we chose not to use @encoding to avoid confusion with XML encoding 00:09:56 agreed, on both accounts, and well put 00:10:29 (I presume you mean character encoding? iso-8859-1/utf-8/etc.) 00:10:43 (that's independent of XML) 00:10:48 I use "mode of encoding" to foster the connection to Content-Encoding. 00:10:59 that's nice too 00:11:19 <-- that encoding 00:11:45 MIME Content-encoding := x-compress, x-zip, x-uuencode, ... 00:12:03 x-xml, x-string, x-escaped :) 00:12:06 same data, different bytes 00:12:09 x-base64... 00:13:15 and some content encodings/modes can only transport certain MIME types? 00:15:57 yes. string and escaped are not 8-bit clean, for example 00:20:17 okay. can we default @mode='escaped' to @type='text/html', and @mode= 00:20:31 'xml' to no type, look at the namespace? 00:21:17 and @mode='string' to text/plain, defaulting elements in general with #PCDATA content to @mode='string' 00:22:55 I know we've been going on this for a long time. feel free to break. I just want to be as clear as I can on it all 00:23:37 I'm also looking at this all from an EF point of view, and I think that Sam's model of requiring rdf:value constructs all the time is the right thing to do for what we've got here 00:23:52 I'd rather not default an encoding mode to specific content types 00:23:56 I'm thinking about @value for when people just want plain untyped literals 00:24:26 if we don't default encoding modes to content types, then we'll have to have two attributes on //title in the case where we're using escaped HTML, for example 00:24:53 Ben &amp; Jerry&apos;s 00:25:04 iirc, aren't rdf apps/tools supposed to support rdf:value and literals almost interchangebly? 00:25:10 is that going to be acceptable? or will people want ? 00:25:54 <sbp> I'm not sure how many do. I don't think that a lot of people think about rdf:value very much; for a long, long time it sat with no specification to tell people what to do with it 00:26:10 <bitsko> the specific case of mode="escaped" I'm not concerned about if it has a type. it probably should, to distinguish text/html from potentionally malformed application/xhtml+xml 00:27:02 <sbp> well either @type is always required, it's only required in some cases, or it's optional 00:28:02 <sbp> and in the cases where it's not present, we either default to some value or we don't 00:30:44 <bitsko> the default mode should be "string" (which is the non-ANY equivalent of the default of "xml" I mentioned earlier) 00:31:03 <sbp> agreed 00:34:14 <bitsko> I'm leaning towards @type being optional. it doesn't matter for text/plain, text/html, or application/xhtml+xml in @mode="string". 00:35:38 <bitsko> it's potentially not applicable in @mode="xml", outside of application/xml being the catch-all for arbitrary XML Namespaces 00:37:20 <sbp> and with @mode='encoded', it's redundant 00:38:35 <sbp> * sbp leans towards transcribing this as is for an RDF model--just taking the information given in the Atom file, and having it copied as closely as possible; if AtomXML and AtomRDF applications will have the same level of data to go on 00:39:13 <bitsko> transcribing the chat? 00:40:06 <sbp> heh. I'd win the LargestWikiPage competition with that. nope, I meant making the Atom => RDF model be as non-interpretative as possible. don't demode/canonicalize, or add any defaults or anything like that 00:41:47 <jcgregorio> jcgregorio has joined #echo 00:41:57 <sbp> @value bugs me... 00:43:09 <bitsko> @value in Atom? 00:43:11 <sbp> perhaps I could reserve @mode="literal" to do straightforward element content mappings to RDF 00:43:30 <sbp> well, the EF. see above, for expessing plain literals 00:43:43 <sbp> <sbp> I'm thinking about @value for when people just want plain untyped literals 00:44:08 <sbp> digressing 00:45:43 <bitsko> +1 to non-interpretive 00:46:24 <bitsko> altho mode of encoding is very much a candidate for change when being gatewayed 00:46:39 <sbp> yes, indeed 00:47:18 <bitsko> the reason I'm thinking that type is optional is that most things are string literals. virtually everything else should have a type. 00:47:54 <sbp> sigh. but you'd still have to use rdf:value... 00:48:01 <sbp> because it makes querying tricky otherwise 00:48:02 <bitsko> I take that back. I don't see the need for type on xml literals, either 00:48:40 <sbp> if you use [ rdf:value "" ] where there's a type and just "" where there isn't, you don't know which to query for 00:48:53 <bitsko> given the context of "a sequence of characters with a 'type' is most definitely 'something else'", the extra difficulty in querying is inherent 00:48:58 <sbp> which is why Sam convinced me to deploy rdf:value for everything last night 00:49:22 <sbp> hmm 00:49:50 <sbp> that's a good point, though it's still distressing 00:50:18 <bitsko> I am very sensitive to "going to a property value, expecting one thing, and finding something completely different", I'm not sure this is one of those cases, tho 00:50:41 <sbp> yes, I see your point, very much so 00:52:24 <bitsko> usually it's in the case of developing a generic library layer, where the library can't tell the difference and has to expose that to the application. the same would hold true in a generic transform. 00:52:34 <sbp> we're leaving it up to applications to fill the types back in, and applications working in RDF can (or should be able to) do that just as much as XML applications 00:52:42 <sbp> yes 00:53:09 <sbp> okay, that's not so bad 00:55:50 <sbp> cool that Sjoerd refactored EF into DocumentMode 00:59:19 <bitsko> <foo type="text/html" mode="xml">Ben & Jerry's <blap> <bar></foo> 00:59:19 <bitsko> <foo type="text/html" mode="xml"><![CDATA[Ben & Jerry's]]> <blap> <![CDATA[<bar>]]></foo> 00:59:19 <bitsko> <foo type="text/html" mode="string">Ben & Jerry's <bar></foo> 00:59:19 <bitsko> <foo type="text/html" mode="string"><![CDATA[Ben & Jerry's <bar>]]></foo> 00:59:19 <bitsko> <foo type="text/html" mode="escaped">Ben &amp; Jerry&apos;s <blap> &lt;bar&gt;</foo> 00:59:20 <bitsko> <foo type="text/html" mode="escaped"><![CDATA[Ben & Jerry's <blap> <bar>]]></foo> 01:00:24 <bitsko> where "blap" is a html element and <bar> is displayed literally, as in, "Ben & Jerry's *!* <bar>" 01:00:46 <sbp> the first one isn't well formed XML 01:01:00 <sbp> nor's the second 01:01:01 <bitsko> "blap" is disallowed from mode="string", as it's mixed content 01:01:16 <bitsko> I'll add the '/' 01:01:22 <sbp> ah, okay 01:02:25 <sbp> yeah, each of those pairs look like they canonicalize equivalently to me 01:02:35 <sbp> in fact, the xml and escapeds both do, too 01:06:44 <bitsko> looking at atomToRDF, earlier I noticed there were no references to Atom specifically, except to supply the URI-base for the encoding modes. now it looks for the root node, and a certain level of nodes? 01:07:02 <bitsko> or maybe I just missed it earlier 01:07:23 <bitsko> I ask in leading up to ask how it can be made completely generic 01:07:29 <sbp> nope, it's always looked for the root node. the root node is what says that it's an AtomEF document. the levels are generic, though 01:08:09 <sbp> it's as generic as it can get, I think 01:08:33 <sbp> you have to specify at the root element what the type of the document is, how it's to be interpreted 01:08:55 <sbp> I was going to try to get around that by using an attribute with a URI value, but that'd not be good web architecture 01:09:19 <sbp> I've converted my FOAF file into Atom, though 01:09:30 <sbp> so it's pretty reusable :-) 01:10:01 <sbp> I've not compared the resulting graphs with an RDF graph matching utility, but I think they're equivalent 01:10:27 <sbp> and the only Atom namespaced node that it required was the root node 01:10:46 <sbp> <atom>[do whatever here]</atom> 01:10:58 <sbp> do whatever, as long as you follow the EF rules, of course 01:11:34 <bitsko> maybe I'm still missing something. can't you just add the rdf:RDF wrapper as the root of the output, and then assume that the root node of the input document is a resource? 01:11:39 <sbp> EF's a bit of a misnomer. it is an extensibility framework, but generally, it's an alternate serialization of RDF that doesn't use a striped model 01:11:57 <bitsko> yes, I caught that :) 01:12:46 <sbp> you can a) ignore the root element and just work as normal or b) treat the root element as a typed node, but both approaches aren't sound. both a) and b) don't actually specify the document type, which will lead to big problems (think of a robot coming across it), and b) moreover restricts you to one typed node 01:13:12 <sbp> heh, sorry. I'm just wondering how to proceed with promoting it... 01:13:36 <sbp> going around saying "hey, new RDF serialization" is probably not a good idea to begin with 01:13:45 <bitsko> * bitsko nods 01:14:37 <sbp> and the cool thing is that it doesn't have to succeed as an alternate RDF serialization--the fact that it is is what's enabling us to add extensions that will map to an RDF model consistently. it'll just be more useful if people reuse it 01:15:05 <bitsko> I'm still stuck. the input root element is <feed>, a resource. what makes it any different from an <entry> or <author> below it? oops, and I think I see a problem with @mode... 01:15:28 <sbp> <feed> level elements are actually taken as typed nodes, not property elements 01:15:35 <sbp> problem with @mode? uh oh 01:15:49 <bitsko> do you mean children of <feed>? 01:16:32 <sbp> nope. <feed> is converted directly to a typed node, as in the typed node production of RDF/XML. its children are converted to propertyElts, and no more typed nodes should ever occur that have been directly converted 01:17:02 <bitsko> hmm 01:18:50 <sbp> the structure/framework in that area is simple and solid, and the transformation section for it hasn't changed since I first made it; @mode and @type are, on the other hand, very worrying. what was the problem with @mode that you spotted? 01:18:53 <bitsko> on the EF page, the "Changes made to the syntax" is not current 01:19:02 <sbp> whoops. checking and fixing 01:19:46 <bitsko> the @mode issue is related to the striping, or lack thereof, which we just started discussing 01:21:16 <sbp> ah 01:21:22 <sbp> do continue, if it's still an issue 01:21:29 <sbp> changes section updated, btw 01:22:06 <bitsko> in ["Syntax"], "Schema Patterns" describes a node-property striping style 01:23:59 <bitsko> basically, any element which has child elements (not marked as a content element) is an "entity". all the children of entities are its properties. (thus, an entity can be a property of its parent) 01:24:46 <sbp> yep. that basically corresponds to resource 01:25:45 <sbp> not sure about an entity being a property of its parent... 01:27:26 <sbp> with EF, there's no way to type a node, except at the base, so there's no way to say that a particular type of entity is a property of its parent. moreover, from an RDF pov, it doesn't make sense to say that a resource is a property of its parent, though I'm probably misinterpreting "Schema Patterns" 01:27:40 <bitsko> essentially, entities are rdf:parseType="Resource", which from the DTD experiment the other day, works very well. 01:28:07 <sbp> okay. they're properties which point to blank nodes? same as the EF, then 01:28:45 <bitsko> yes, I think putting the two together can simplify and more genericize atomToRDF 01:29:49 <bitsko> the biggest problem (or solution waiting to happen, depending on how you look at it ;) is @mode 01:29:59 <sbp> I have a feeling that atomToRDF already does things in exactly that way... if it doesn't then yes, the differences will be interesting to note 01:30:34 <sbp> (solution waiting to happen sounds excellent) 01:30:34 <burtonator> burtonator has joined #echo 01:34:33 <bitsko> oh. I'm surprised rdf:parseType="Resource" doesn't pick up the element's type name as its rdf:type 01:34:40 <rubys> back... I just scanned ExtensibilityFramework... is the <value> supposed to be there at the bottom? 01:35:01 <rubys> also, the first line, shouldn't that be "does not use RDF/XML"? 01:35:24 <bitsko> but, I'm given to wonder the benefit of having the <feed> element be typed when all the rest are not, but it's very possible the transform can do that better than the DTD 01:36:39 <rubys> also, just curious, why was an <atom> element added? 01:37:33 <bitsko> in particular, one of the use-cases I see for Atom is to have many entity types that can be used standalone. assuming the "main" entity type is <feed> is bad, in that case 01:37:40 <sbp> it doesn't pick up its name as an rdf:type because it's being used as a property, not a class. otherwise, there's no way to relate it, and you fail to transform 01:38:27 <sbp> <atom> was added because otherwise there'd be no way to reuse it. if feed were at the root, how would one specify that you were using this model in the case that you weren't using <feed>s or anything else from Atom the syndication language? 01:38:37 <bitsko> rubys: the <atom> element is one of the things we're talking about, I'm thinking there's a way back 01:40:04 <bitsko> sbp: I think "rdf:type because it's being used as a property" is incorrect. <entry>, <author>, and <contributor> *are* classes 01:41:11 <bitsko> in ["Syntax"], entities == RDF classes 01:41:35 <sbp> let's just take feed and entry for now. currently, with the EF, feed is a class and entry is a property. you get something like: [ rdf:type :feed; :entry [] ] . now, if :entry were a class, you'd have [ rdf:type :feed; ??? [ rdf:type :entry ] ] . what do I use to fill in the ??? 01:41:40 <bitsko> er, entities == Resources. whether or not they are typed correctly may be a seperate issue 01:41:48 <sbp> exactly 01:42:14 <bitsko> <feed> and <entry> are, to me, clearly typeable resources 01:44:21 <bitsko> in looking at http://intertwingly.net/stories/2003/08/10/minAtom.rdf in the RDF validator, it appears to create a blank node as an atom:entry property of the feed 01:44:53 <sbp> again, what property do I use to relate <entity> to <feed> if entity is a class name? 01:44:54 <bitsko> so, it would continue to be [ rdf:type :feed; :entry [] ] 01:45:12 <sbp> yep. Aaron's model uses entry as a propertyElt 01:45:45 <bitsko> yes, more or less that's inherent to using rdf:parseType="Resource" 01:46:39 <bitsko> actually, I said blank node above where I should have said untyped node 01:46:56 <sbp> both are true, though 01:48:54 <bitsko> the distinction I'm seeing is between <atom><feed><entry> being untyped, where <atom><entry> suddenly becomes typed by virtue of picking it up from a different URI-location. I'm suggesting that either the root element become untyped, or come up with a way to type elements. 01:49:50 <bitsko> one way (testing the waters here) to type other entities is to use their element's name as both the parent's property and the resource's type. 01:50:46 <bitsko> in effect, that's how <feed> is becoming a type, by virtue of its location. 01:51:36 <sbp> rdf:Property and rdfs:Class are disjoint 01:52:10 <sbp> and then you'd be using one URI to denote two things 01:52:52 <sbp> but I see your point about entry suddenly becoming typed by shifting it to a node position 01:53:02 <sbp> I'd recommend capitalizing it in such a case 01:53:06 <sbp> <atom><Entry> 01:53:39 <rubys> Eeek. Avoid caps. 01:53:40 <bitsko> iirc, capitalization is not I18N portable 01:54:37 <bitsko> I'd think of munging the name in some other way. 01:55:49 <bitsko> suffixing 'RDFClass' or something obnoxious like that 01:55:55 <sbp> eek 01:56:21 <sbp> that's horrible 01:57:01 <sbp> sorry. I refactored EF slightly to make it easier on people coming to it with no context 01:57:07 <sbp> thinking about typing... 01:58:31 <sbp> I don't think local-name munging in general is a good solution. if people want to use classes, they ought to specify what the names of those classes are in the document 01:59:38 <sbp> it won't work, anyway, for oddly split namespaces. e.g. where you have people using atomf:eed 01:59:39 <bitsko> that seems reasonable. what I would suggest, then, is not worrying about the root element's type, either. just use rdf:Description 01:59:48 <sbp> okay, that's fair enough 02:00:20 <sbp> so atom:feed becomes nothing at all? 02:00:36 <sbp> hmm 02:01:08 <bitsko> yes. that's ok. RDF-wise, the untyped node that becomes an <atom:entry> property of the feed is also "nothing at all". 02:01:35 <sbp> I was just thinking about the reusability case 02:02:31 <sbp> just a hmm, not an "eek" or a "no!" :-) 02:02:43 <bitsko> if there's no way to specify class (of which there may be a way for EF but just not used by Atom), I'm comfortable with the root node becoming an untyped resource. 02:03:02 <sbp> correct, and yes, I agree 02:03:17 <sbp> (just use <rdf:type>, btw) 02:03:38 <bitsko> ya, something like that :) 02:03:59 <sbp> actually, :feed is alright for relating feeds to whatever feeds may be related to. atom:weblog? :-) 02:04:40 <bitsko> k. now, back to where this is affected by @mode. 02:04:46 <sbp> heh. <atom><feed id="#myfeed"><author><weblog><feed href="#myfeed"/></></></></> 02:04:59 <sbp> ah. okay. back to the uh oh 02:05:27 <sbp> * sbp tries to keep track of the changes required for the next update to atomToRDF 02:05:52 <bitsko> @id is one way to indicate an element is a resource, but I don't think it should be the principle way. 02:06:19 <sbp> ./* is the principal way 02:06:33 <bitsko> ./* == has children elements? 02:06:43 <sbp> well, ./* and not(@mode) 02:06:44 <sbp> yes 02:07:03 <sbp> for example, if you took @id off of <entry>, it'd work just fine 02:07:45 <bitsko> ah, and you may have answered the other issue, especially now that mode="string" is the default. if it has children and no mode, it's a resource. 02:08:20 <bitsko> s/children/element children/ 02:08:37 <sbp> yep. I should document this all on wiki:EF, and am trying! it's all formalized in the XSLT for now, but better to move it out into prose sooner rather than later 02:08:56 <bitsko> you've updated the XSLT? 02:09:37 <sbp> it's not been updated to detype the atom:atom/* nodes and structure @mode and @type as we've decided today, no 02:11:53 <sbp> detyping's done 02:11:57 <sbp> but that's the easy thing 02:17:26 <emanu> emanu has joined #echo 02:26:05 <bitsko> I missed http://www.w3.org/DesignIssues/Syntax.html when it was chumped earlier in #rdfig 02:28:44 <sbp> I think sergey melnik came up with something very similar too 02:29:21 <bitsko> hmm, maybe that's not relevant 02:29:56 <jcgregorio> jcgregorio has left #echo 02:30:09 <sbp> ah. it's linked from the bottom. http://www-db.stanford.edu/~melnik/rdf/syntax.html 02:30:41 <sbp> melnik's also defaults to Resource 02:31:04 <bitsko> I read, " It is basically as the M&S syntax with parseType=resource is a default." and assumed too much ;) 02:33:53 <sbp> heh, yes. it's not quite the same... 02:35:43 <bitsko> not surprising that people have been thinking about this topic for an eternity... 02:39:27 <sbp> sadly not. the RDF/XML syntax isn't bad, and for some things is probably as close to optimal as you're going to get in XML, but it's just that for some things it's really constraining. it was nice that dajobe said, I think on www-rdf-interest the other day, that RDF/XML could benefit from many years of suggested improvements 02:39:43 <sbp> * sbp is still hacking on the XSLT, trying to simplify and clarify, and make sure everything works properly 02:43:11 <sbp> <simple>value</simple> 02:43:11 <sbp> => :simple "value" 02:43:11 <sbp> <simple mode="string">value</simple> 02:43:11 <sbp> => :simple "value"^^atom:string 02:43:11 <sbp> <simple mode="xml">value</simple> 02:43:11 <sbp> => :simple "value"^^rdf:XMLLiteral 02:43:14 <sbp> <simple mode="xml"><value xmlns=""/></simple> 02:43:15 <sbp> => :simple "<value xmlns=\"\"/>"^^rdf:XMLLiteral 02:43:17 <sbp> <simple mode="string" type="text/blargh">value</simple> 02:43:19 <sbp> => :simple [ :type "text/blargh"; rdf:value "value"^^atom:string ] 02:43:21 <sbp> <simple mode="xml" type="application/splunge+xml"> 02:43:25 <sbp> <value xmlns="splunge:"/> 02:43:27 <sbp> </simple> 02:43:30 <sbp> => :simple [ :type "application/splunge+xml"; 02:43:31 <sbp> rdf:value "<value xmlns=\"splunge:\"/>"^^rdf:XMLLiteral ] 02:46:57 <bitsko> looks good 02:48:03 <sbp> I'm rather pleased with the implementation, too; type gets automatically converted by virtue of a nice bit of helpful code 02:51:16 <bitsko> <sbp> <simple>value</simple> 02:51:16 <bitsko> <sbp> => :simple "value" 02:51:16 <bitsko> <sbp> <simple mode="string">value</simple> 02:51:16 <bitsko> <sbp> => :simple "value"^^atom:string 02:51:48 <bitsko> if mode="string" is the default, shouldn't these both produce the same result? particularly, no ^^atom:string 02:52:58 <bitsko> * bitsko wonders idly at the use of two ^^ carets 02:55:05 <sbp> well, I'm just going by the no-interpretation rule, which means no defaulting 02:55:42 <sbp> Atom parsers will know that mode="string" is the default, and so should Atom RDF implementations 02:56:08 <bitsko> k. sounds good 02:56:26 <sbp> * sbp checks the XSLT, double checks it, triple checks it... 02:58:02 <sbp> * sbp spots a very, very subtle error 02:58:13 <sbp> which may or may not be an error any day now 02:58:42 <sbp> (huge RDFCore debate over whether xml:lang and datatypes can be used simultaneously on literals) 03:21:17 <sbp> okay, the stuff at http://infomesh.net/2003/atomef/ has been updated. untyped atom:atom/* nodes, and the new literal value structuring outlined above 03:23:57 <Arien> Arien has joined #echo 03:25:18 <bitsko> I'm still uncomfortable that mode="escaped" implies X/HTML 03:27:40 <sbp> me too. but it won't be so bad once documented carefully. unless you have some technical reservation? 03:30:22 <bitsko> <foo mode="escaped" type="application/foo+xml"> isn't X/HTML, for example. 03:31:35 <bitsko> I might just be getting picky, tho 03:32:34 <Arien> * Arien is reading the logs but wonders what good 'mode' and 'type' do in the mean time. 03:32:48 <bitsko> did we come to a conclusion on atom:atom? 03:33:50 <bitsko> Arien: mode and type refer to the "blocks of text or markup" in certain elements that allow free-form text 03:34:16 <bitsko> also to elements that allow more than just text, like graphics and such 03:35:14 <bitsko> the most concrete example is, "how much different is 'title' from 'content'". 03:36:27 <bitsko> the context of most of the discussion today has been on two topics: 1) making sure the model is clean, and 2) using a mapping to RDF to help with (1) 03:37:17 <bitsko> sbp: are the two cases using atom:atom still necessary? 03:37:19 <Arien> Escaping doesn't seem very clean... 03:38:19 <bitsko> Arien: no, but we have no choice. there are a lot of archives and tools in the wild that can't support anything but escaped. 03:38:34 <Arien> And I'd think using namespaces would work better than the 'type' attribute? 03:38:45 <sbp> the two cases using atom:atom? 03:39:13 <bitsko> <xsl:when test="../atom:atom"> and <xsl:when test="../../atom:atom and (@id|./*)"> 03:39:33 <sbp> ah. yes. very much so 03:40:03 <sbp> but let me try to convince you on this 03:40:29 <Arien> bitsko: What xml tools lack that support? 03:40:54 <bitsko> Arien: blog tools, not xml tools 03:41:46 <sbp> the simple argument is: if you come across a document that has <atom:atom> as its root document element, then you know that you can parse it using the EF rules; if you come across a document which uses the EF rules but which doesn't have atom:atom as its root element, how do you know that it uses the EF rules? 03:41:48 <Arien> Yeah, they lack support for TFNCE (the format not called Echo) as well... 03:42:14 <Arien> So the question is really: how bad do people want it? 03:42:40 <bitsko> good point. 03:44:24 <Arien> Too me it seems that all the escaping business is hurting a lot more than it's helping. 03:44:36 <Arien> s/Too/To/ 03:49:45 <bitsko> sbp: how about any document whose root is the AtomNS? 03:49:54 <bitsko> s/root is/root is in/ 03:54:01 <bitsko> particularly when one is spidering and comes across a root element namespace URI, or any namespace URI for that matter, pointing to a RDDL doc saying it's conforming. 03:54:31 <sbp> sure, that works. I just change atom:atom to atom:* 03:54:47 <bitsko> I want more!!! 03:54:59 <bitsko> I want EF written up as its own micro-spec! 03:55:05 <sbp> heh. you want to use any element at the roo... haha 03:55:21 <sbp> I know, I know. well, I updated the tutorial a little bit! 03:57:12 <bitsko> right now, atomToRDF.xsl is tied directly to the Atom format. (indirectly, the encoding types are tied too, but that's a seperate matter) 04:10:48 <sbp> see ExtensibilityFramework 04:10:56 <sbp> I'm making a start on specificationarizing it 04:11:50 <sbp> my worry is that since it's being updated a lot, I'm just going to lose track and make a mess 04:12:11 <sbp> at least with the XSLT, it's solid *code*: I can run it, validate the results, and so forth. I know that it works, and I know what the current state of play is 04:15:30 <bitsko> Atom is being updated a lot? I think something like EF will help to shape *where* that updating is happening. 04:15:57 <bitsko> EF is, in code, kinda what I was shooting for in ["Syntax"] as a design pattern. 04:16:02 <sbp> the EF is being updated a lot, and Atom is being updated a lot in terms of @type/@mode 04:16:05 <sbp> yeah... 04:18:09 <bitsko> I gotta go sleep. today's been good on the Atom front :D 04:19:06 <sbp> sleep well, Ken. thanks for all of the input today--it's been a long day, and agreed on major progress 04:19:13 <bitsko> on an ending note, how come *we* can't come up with a good name like Xouvert? 04:19:20 <sbp> hehheh 04:19:30 <sbp> perhaps we should ask those guys for a name 04:20:04 <Arien> We could just (partly) translate a proposed name like they did ;-) 04:20:17 <bitsko> oh yea, I remember. Lokahi is too hard to pronounce, unlike Xouvert or Linux. 04:20:21 <Arien> Or didn't really 04:21:11 <Arien> What does lokahi mean again? 04:21:28 <sbp> I find myself oddly coming round to Atom. I think it's awful, but since it's being used a lot, I'm starting to get comfortable with it... 04:21:51 <sbp> "LOKAHI means UNITY and HARMONY in Hawaiian" 04:21:58 <Arien> * Arien is still reading the log... Today was productive alright.. 04:22:04 <sbp> - http://www.intertwingly.net/wiki/pie/NameItEchoConflict 04:22:06 <sbp> heh, heh 04:23:16 <sbp> wow, the RDF logs for today/yesterday were nearly half a meg. great! 04:23:30 <sbp> I feel sorry for bitsko's box, though 04:25:04 <bitsko> nah, those are on the PVR partition. compared to video, RDF is nothing :) 04:25:10 <Arien> http://bitsko.slc.ut.us/chatlogs/echo/2003-08-17.html#T23-40-38 this is just silly. 04:27:31 <bitsko> half of that is just using basic XML to highlight the difference (CDATA). escaped is what we have to live with. the only new thing is "string", which pretty much means the same thing as "xml", but #PCDATA instead of ANY. 04:27:38 <Arien> Ken: you weren't serious, were you? 04:29:03 <bitsko> I was. what would you toss to make it simpler? 04:29:36 <bitsko> (more precisely, that wasn't a proposal, but a summary of the discussion) 04:30:56 <Arien> I wouldn't make it simpler... What I would do is not make it more dificult than it is (because of XML). 04:31:31 <bitsko> one of the key statements in the log is at http://bitsko.slc.ut.us/chatlogs/echo/2003-08-17.html#T23-06-04 04:32:27 <Arien> """there's a balance between being overzealously consistent and human readable, but I think we're doing well so far""" 04:32:51 <bitsko> we're not just defining a core set of properties, but also a model to be followed when extending that core 04:34:33 <sbp> (and it turns out that only one attribute that we were talking about, @mode, has to belong to the core) 04:34:54 <bitsko> this area of complexity surrounds the design of <title>, <summary>, <content>, and extensions like them. 04:35:09 <Arien> I think trying to squeeze everything into XML syntax (not spirit, mere syntactic rules) is consistency gone wild. 04:36:06 <sbp> what would one use if not XML syntax? 04:36:47 <Arien> I'm not arguing against XML syntax. ;-) 04:37:34 <Arien> Why would you need escaping? 04:37:55 <Arien> (Or more precisely: why would you need more escaping mechanisms than XML offers anyway?) 04:38:34 <Arien> The answer is: "to stick XML-incompatible stuff in XML", right? 04:38:41 <bitsko> text/plain or text/html escaping? 04:39:32 <Arien> What's the difference, Ken? 04:41:20 <Arien> I would argue that there are two ways to deal with well-formed content: 04:41:26 <bitsko> @type. in the case of text/html, the content may be malformed. we seem not to be able to convince a large base of implementors that we can do otherwise. 04:41:35 <Arien> 1. Link to it. Problem solved. 04:42:03 <Arien> 2. Rewrite the content as XML, no escaping. 04:43:35 <bitsko> * bitsko awaits </end> 04:43:46 <Arien> "no escaping" meaning that "This is<br>HTML." would be "This is<br />HTML", *not* "This is<br>HTML." 04:43:48 <bitsko> oh, n'ermind. "two ways" :) 04:43:54 <Arien> heh 04:44:23 <bitsko> I'd vote with you on that. my feeling is that we've already been firmly outvoted on this one. 04:44:51 <Arien> That'd be a shame. A real shame... 04:45:44 <Arien> How would that be better that the insanity of the RSS "spec" on this point...? 04:46:16 <Arien> Oh, well... 04:46:27 <bitsko> the RSS spec doesn't say when one is using escaped or xml. simply that. 04:47:40 <Arien> Not the escaping, the warped (that's being nice) design (that's flattery) 04:48:48 <Arien> Guess I was hoping that TFNCE would do The Right Thing here... 04:48:59 <bitsko> define "The Right Thing" 04:49:05 <Arien> heh 04:49:22 <Arien> The Right Thing as in: use XML the way it was meant to be used. 04:49:47 <bitsko> as document markup? 04:50:01 <Arien> Yeah... As universal, open, document markup. 04:50:20 <Arien> The encoding makes things harder instead of easier. 04:51:07 <Arien> Supposedly easier on some producers of content, harder on consumers. 04:51:36 <bitsko> several implementors have said *exactly* the opposite. 04:51:43 <Arien> And there's other issues... 04:52:11 <bitsko> Brent Simmons (NetNewsWire) wants *only* encoded content. 04:52:28 <Arien> For example: <foo type="tex/plain">¿</foo> is legal or not? (And why.) 04:52:59 <Arien> *Only*? What good would that do him? 04:54:15 <bitsko> http://intertwingly.net/wiki/pie/EscapedHtmlDiscussion 04:55:25 <Arien> * Arien is reading "Escape everything"... 04:56:42 <Arien> 2. is saying XML will never work 04:57:02 <Arien> so then why do this whole thing in XML in the first place? 04:57:39 <bitsko> actually, (2) is saying end-users put things between <content> tags, when in fact tools do. 04:57:39 <Arien> 1. ("chunk of data"): If want to treat content like a chunk of data, go right ahead. 04:58:49 <Arien> Not end-users, toolbuilders... Seems to me they think they could build tools that would work properly. 04:59:00 <Arien> s/could/couldn't/ 04:59:20 <Arien> That's more or less what they're saying, anyway. 05:00:41 <bitsko> <Arien> For example: <foo type="tex/plain">¿</foo> is legal or not? (And why.) 05:00:58 <bitsko> that's legal for a <foo> element, why wouldn't it be? 05:01:37 <Arien> What is the default charset for text/plain? 05:01:47 <Arien> Isn't it ASCII? 05:01:48 <bitsko> same as the surrounding document instance 05:02:28 <Arien> The MIME type of the foo element would decide what is legal within foo, no? 05:03:03 <Arien> Or is it just the type of the content, written in XML? 05:05:33 <bitsko> the content of elements can be: XML Character Data (newly defined as "string", the default, in the charset of the surrounding document), mixed content ("xml", mixing elements and character data, in the charset of the surrounding document), escaped markup ("escaped", in the charset...), and base64. 05:06:39 <Arien> Hmm... 05:06:39 <bitsko> only base64 supports octet-based resource entities, all the rest are XML Character Data modes of content encoding 05:08:38 <Arien> What does escaping buy? 05:08:50 <bitsko> concession. 05:09:06 <Arien> hehe I meant on a technical level. ;- 05:09:08 <Arien> :-) 05:10:07 <bitsko> two things that I see: 1) straightforward serialization of archived potentially malformed markup, and 2) migration support for tools that don't tidy. 05:11:19 <Arien> So why stop at the contents of <content> (and others)? 05:11:40 <Arien> There will be broken tools that forget to escaped <lastModified>... 05:11:51 <Arien> See where I'm going? 05:12:11 <Arien> s/forget to escaped/forget to end/ 05:12:25 <Arien> eg: "<lastmodified>blabla" 05:12:55 <bitsko> and they do already and will continue to do so. syndic8 is full of broken feeds that are, sadly to report, parsed just fine by many current aggregators. 05:13:29 <bitsko> in this arena, that's considered a "feature" 05:13:36 <Arien> It's the same argument over and over again: "There will be broken tools, so we'll need to break the spec to accomodate them". Say *what*? 05:13:58 <sbp> bitsko: there's the start of a formal grammar at the bottom of ExtensibilityFramework now... 05:14:57 <sbp> now that I think about it, it might be worth my while writing a recursive descent parser for it 05:15:03 <sbp> then we can get the grammar from that 05:15:07 <bitsko> sbp: egads! 05:15:23 <sbp> ...I'll take that as a bad egads 05:15:32 <sbp> what's up? 05:16:44 <bitsko> egads was to writing a parser :) looking at the page tho, I would shuffle the grammar off to another page. might scare the readers who would otherwise warm to the idea. 05:17:29 <sbp> ah, okay. any suggestions for page title? I'd use ["EFGrammar"], but it might be better to use a WikiWord if you can think of one 05:18:38 <Arien> Ken: use Parse::RecDescent; 05:19:12 <sbp> or Python. yeah. better use Python :-) 05:19:27 <bitsko> sbp: go for the longname, ExtensibilityFrameworkGrammar is fine 05:19:47 <bitsko> only have to type it once or twice ;) 05:19:55 <Arien> sbp: Whatever works... 05:20:47 <sbp> okay, making it 05:21:02 <bitsko> besides "escaped", which is something I think we actually agree on, what other issues are there? 05:23:20 <Arien> @type but I guess that's been and gone as well... 05:24:36 <Arien> I haven't been able to follow things real close the last couple of days. 05:26:05 <Arien> Not sure if it's been mentioned lately: having author info external to the feed. 05:26:21 <bitsko> @type is questionable for most literal element content (the discussion about either using a single attribute to indicate type+encoding, or inferring the type from the encoding). it's mostly to be consistent and extendible like <content>. content's @type is a MIME media type to support editing and distribution of media content (either inline or by reference) 05:27:42 <bitsko> no one's mentioned loudly about having author info external. <author href="http://example.com/me.foaf"/> would be a grand idea. 05:27:44 <Arien> If it's inline it would possibly lead to escaping "needs". 05:28:01 <Arien> If it's by reference then there's HTTP's Content-Type for that. 05:29:33 <Arien> http://intertwingly.net/wiki/pie/EchoFeedWithAuthorRefs near the end 05:29:52 <Arien> """[Arien, RefactorOk] I propose having author info completely external to the feed: every author should have a URI. The analogue case for a URI for every entry is discussed in RestEchoApiOneUriForEachEntry.""" 05:32:31 <bitsko> I'm highly in favor of spreading the xml fragments around. I kinda think <feed>s shouldn't even have their <entry>s embedded. 05:33:14 <bitsko> I'll reemphasize, "no one's mentioned loudly" :) 05:33:45 <bitsko> sbp: I'm a little tired to make sense of the grammar. I'll look again tomorrow 05:33:50 <bitsko> er, today 05:34:07 <Arien> afk 05:34:14 <bitsko> it _seems_ a little more complex than I'd expect 05:35:46 <bitsko> * bitsko runs off to bed during the lull. g'nite! 05:39:33 <sbp> yeah, I'd better run too 05:39:46 <sbp> it does look a bit complex... sigh 05:39:50 <sbp> anyway, thanks all 07:00:17 <imajes> imajes has joined #echo 07:10:55 <d2m> d2m has joined #echo 07:17:34 <burtonator> burtonator has joined #echo 07:53:50 <stecay> stecay has joined #echo 08:16:30 <sjoerd_visscher> sjoerd_visscher has joined #echo 08:38:13 <burtonator> burtonator has joined #echo 08:43:38 <Netmonger> Netmonger has joined #echo 08:45:46 <danbri> danbri has joined #echo 08:46:06 <burtonator_> burtonator_ has joined #echo 09:07:24 <KevinMarks> KevinMarks has joined #echo 09:16:19 <burtonator> burtonator has joined #echo 10:07:18 <burtonator> burtonator has joined #echo 10:18:02 <protocol7> protocol7 has joined #echo 11:19:57 <stecay> stecay has joined #echo 11:19:57 <d2m> d2m has joined #echo 11:19:57 <jbeimler> jbeimler has joined #echo 11:19:57 <Netminder> Netminder has joined #echo 11:20:06 <danbri> danbri has joined #echo 11:20:06 <imajes> imajes has joined #echo 11:20:06 <bear> bear has joined #echo 11:20:06 <datum> datum has joined #echo 11:40:07 <Arien> Arien has joined #echo 11:49:49 <Netmonger> Netmonger has joined #echo 11:52:50 <rubys> rubys has joined #echo 12:00:31 <dhaun> dhaun has joined #echo 12:01:41 <emanu> emanu has joined #echo 13:18:27 <rubys> rubys has joined #echo 13:49:55 <rubys> * rubys coughs 13:53:04 <Arien> * Arien looks up from his code 14:05:16 <ktest> ktest has joined #echo 14:08:46 <Znarf> Znarf has joined #echo 14:21:47 <bitsko> morning! 14:22:34 <sjoerd_visscher> hi! finally the kickoff!? 14:22:51 <Arien> morning Ken! 14:26:43 <Netmonger> Netmonger has joined #echo 14:28:50 <jcgregorio> jcgregorio has joined #echo 14:42:30 <rubys> rubys has joined #echo 14:44:18 <rubys> * rubys shifts restlessly 14:45:52 <sjoerd_visscher> * sjoerd_visscher really liked yesterday's conversation and is eager to continue 14:46:38 <rubys> me2 14:47:11 <sjoerd_visscher> but no lifesigns of sbp yet 14:47:55 <rubys> "sbp has been idle 9hrs 7mins 41secs" 14:53:08 <deusx> deusx has joined #echo 14:53:20 <rubys> Hi les. 14:53:33 <deusx> Hello there! 14:56:19 <Znarf> sjoerd,ruby> what was the conversation about ? 14:57:02 <sjoerd_visscher> escaping and datatypes and rdf 14:57:12 <sjoerd_visscher> you can read the logs 14:59:24 <Znarf> ok, thanx 14:59:34 <ktest> Where are the logs? 14:59:55 <Arien> http://bitsko.slc.ut.us/chatlogs/echo/ 15:00:03 <ktest> Thanks 15:03:36 <bitsko> the discussion is also captured in code described and linked from http://intertwingly.net/wiki/pie/ExtensibilityFramework 15:07:18 <ktest> The example seems comprehensible 15:10:32 <sbp> * sbp staggers in 15:11:30 <rubys> Welcome! 15:12:19 <sbp> heh: "Bob's Blogamatic" 15:12:22 <sbp> hey Sam 15:12:39 <sbp> * sbp is trying to catch up on the state of things, quickly 15:12:51 <sjoerd_visscher> hello sbp, you missed nothing 15:12:53 <rubys> seemed consistent with the rest of the entry. ;-) 15:13:25 <sbp> ah, Asbjorn likes it. that's good 15:13:34 <sbp> heh, yes. it's neat 15:13:39 <sbp> hey Sjoerd 15:14:04 <sjoerd_visscher> I had some questions about the xsl 15:14:20 <KevinMarks> KevinMarks has joined #echo 15:14:22 <sbp> okay. it's been updated per a bit of discussion that Ken and I continued last night 15:14:35 <sjoerd_visscher> if I read correctly you say you have added the atom element for the xsl? 15:14:54 <sbp> atom:*/* nodes are now typeless, and it uses a new model based on all our type/mode disucssions 15:15:00 <sbp> yes 15:15:16 <sbp> whoops: I provided the rationale for that last night, and meant to add it to the wiki 15:15:35 <ktest> * ktest 's head starts hurting when looking at http://intertwingly.net/wiki/pie/ExtensibilityFrameworkGrammar 15:15:40 <sjoerd_visscher> why not remove the atom element and make /* typeless 15:15:47 <sbp> ah: 03:41:46 <sbp> the simple argument is: if you come across a document that has <atom:atom> as its root document element, then you know that you can parse it using the EF rules; if you come across a document which uses the EF rules but which doesn't have atom:atom as its root element, how do you know that it uses the EF rules? 15:15:55 <deusx> Mmm... grammars. 15:16:27 <sbp> yes. I'm going to be working on the grammar a bit today, I think... 15:16:30 <sjoerd_visscher> maybe you know it uses the EF rules because it is targeted at the EF xsl? 15:17:02 <sbp> I'd like there to be many more implementations than the XSLT; or rather, I'd like the XSLT not to be required 15:17:43 <sjoerd_visscher> but that doesn't mean you can require EF documents as the input for the EF xslt 15:17:53 <sbp> that's part of the reason for doing this--for those that feel that XSLT is too much of a burden, they can choose other routes. I myself will probably be using SAX 15:17:54 <sjoerd_visscher> s/can/cannot/ 15:18:07 <rubys> I'm quite willing to write or contribute to native Java and Pyton example parsers based on SAX 15:18:38 <sbp> I planned on writing a Python impl. some time today or tomorrow depending on what we're doing 15:18:39 <bitsko> http://bitsko.slc.ut.us/chatlogs/echo/2003-08-18.html#T03-41-46 15:18:49 <rubys> could also do Perl, C# and a few other languages 15:18:52 <sbp> Sjoerd: I don't understand your last statement 15:19:21 <sbp> wow, a Cowan/Connolly-esque polyglot 15:19:28 <sjoerd_visscher> I don't see why your EF xslt is ever going to encounter non EF files 15:21:02 <ktest> bitsko: Ken, do you or Sean have a link to more info about XIOR, which is mentioned in yesterday's chat? 15:21:06 <sbp> Sjoerd: ah, I see. that's not the problem. the problem is when you have a file that doesn't use the <atom:atom> root element, and it's, for example, automatically crawled by a parser that can understand EF--perhaps a SAX parser. how is that SAX parser to understand that the document is an EF document? now, it could look for a stylesheet transformation in the form of an XML-stylesheet PI, but then that'd make it render as RDF in browsers and so forth, and perhaps 15:21:21 <sbp> XIOR: http://tap.stanford.edu/xemantics.html 15:21:26 <rubys> I think the goal is that a generic RDF parser thing could look at the top element to decide how to consume the document. If it is rdf:RDF, then RDF/XML. If atom:atom, then AtomEF. 15:21:27 <ktest> Thanks 15:21:28 <sbp> see also: http://www.intertwingly.net/blog/1567.html 15:21:42 <bitsko> my proposal for the root element production, in place of documentElt and baseEntityElt, is: document := simplePropertyElt 15:21:51 <sbp> right. it's the namespace of the root element which defines a document 15:22:33 <bitsko> ktest: http://tap.stanford.edu/xemantics.html 15:22:49 <sbp> bitsko: yeah, I've been wondering if that's possible, but then currently the differece between baseEntityElt and simplePropertyElt is that baseEntity throws the element name away, whereas simpleProperty uses it as a property/arc/edge 15:23:02 <sjoerd_visscher> my concern is that this is a very generic thing, and requiring a special root element hurts that a lot, see rdf:RDF 15:23:27 <sjoerd_visscher> I can think of better indicators, like a special PI 15:23:41 <sjoerd_visscher> (that's what PIs are for) 15:23:45 <bitsko> sbp: that's not a grammar issue, merely a parse-recursion issue. iow, written in the prose 15:24:11 <ktest> bitsko: Got it, thanks. "allows us to specify such relations not just between objects in a single document, but also between objects on different sites" yes and what happens when there is a power outage? :) 15:24:20 <sbp> "He concludes correctly that the root namespace (the namespace of the document element) [or a DOCTYPE, which I will not discuss further] is the only thing one must be able to dispatch on" - http://www.w3.org/DesignIssues/XML 15:25:35 <sbp> Sjoerd: yes, I can definitely see that. I understand that part of the reason for the EF is because people are so opposed to having to put up with stuff like rdf:RDF, and that requiring such things for Atom's EF may hurt that just as much... a PI would be an idea, but again, it has problems--it's not grounded in the Web 15:26:15 <sjoerd_visscher> "not grounded" in the sense TBL is talking about? 15:26:32 <sbp> bitsko: it's true that the grammar will stand up by converting... I think I'll follow your advice and simplify it in that way. I want to change the production names to make them shorter, too 15:26:45 <sbp> not grounded: yes. this has come up as a TAG issue; hang on a sec. 15:27:37 <sjoerd_visscher> I see EF as a facet orthogonal to the document type 15:27:46 <bitsko> sbp: last night while my eyes were closing and I said the grammar was complex, it was because I didn't see the seperation between synopsis at the top and description below. I've since added a line seperating the two. other than the document production I just mentioned, it's quite simple 15:27:56 <sbp> http://www.w3.org/2001/tag/ilist#mixedNamespaceMeaning-13 15:28:29 <sbp> bitsko: ah, that's good. I'm glad you find it readable. I was tired myself last night when I composed it, and I was worried it'd make less sense in the light of day (though the sun was coming up!) 15:28:49 <sjoerd_visscher> "It is acknowledged that there are exceptions to this rule, for example XSLT documents whose root element's namespace depends on the desired output from application of the XSLT." 15:28:53 <sjoerd_visscher> EF is the same 15:29:34 <ktest> * ktest thinks nice syllogism: Dawn breaking 15:30:01 <ktest> Blessed are they that see the complexity and the simplicity 15:32:38 <sbp> hmm 15:33:24 <sbp> I don't think that EF is an XML function. it's not necessarily transformed to anything... if that were the case, then RDF/XML would be an XML function too 15:33:55 <sbp> * sbp checks his terminology on "XML function"--means it to mean an XML document which doesn't have to follow the namespace dispatching rules 15:33:58 <sjoerd_visscher> it is, rdf:RDF is weird too 15:34:17 <sbp> ah, yes: " A common class of foreign element name, called here XML function, has to be recognized anywhere by any supporting application, and returns more XML when it is elaborated." 15:34:39 <sbp> see, XF mightn't return "more XML". it might return triples, or it might return a non-XML document type, like N3 15:34:56 <sbp> you can XSLT to N3, of course, but not to triples 15:35:16 <sjoerd_visscher> I think XML function should mean: takes generic XML 15:36:04 <sjoerd_visscher> the output might not be important (although this was clearly not considered there) 15:37:05 <ktest> Sjoerd, could you translate "facet orthogonal to DTD" into language for the RDF-challenged? 15:37:41 <ktest> I am having trouble understand what you mean by that... 15:37:47 <sjoerd_visscher> something that can be added regardles of the DTD (in most cases) 15:38:09 <ktest> ah 15:38:39 <sbp> hmm. I guess that one can consider XSLT to be a good case for XML function, and so let's compare it to EF. how does a parser know that it's getting an XSLT file? I suppose because it's parsing it in an XSLT context--it knows that since it's an XSLT engine, this had better be XSLT it's being given. so that would support your point of view on this 15:39:05 <bitsko> RDDL provides a place for everything that is facet orthogonal for a document type (namespace), to put it in another context. 15:40:25 <bitsko> sbp, sjoerd_visscher, I'm missing what "it" is. are we referring to a document instance that conforms to EF or an EF transform process/tool? 15:40:44 <ktest> * ktest desperately looking for Acronym Finder for RDDL 15:40:59 <bitsko> .acronym rddl 15:41:06 <datum> Resource Directory Description Language 15:41:14 <bitsko> .google rddl 15:41:15 <datum> rddl: http://www.openhealth.org/RDDL/ 15:41:17 <sjoerd_visscher> cool 15:41:37 <ktest> Thanks 15:42:09 <sbp> bitsko: I'm not sure where I've been referring to "it", but I'll guess the former 15:42:41 <sjoerd_visscher> <sbp> hmm. I guess that one can consider XSLT to be a good case for XML function, and so let's compare it to EF. how does a parser know that it's getting an XSLT file? I suppose because it's parsing it in an XSLT context--it knows that since it's an XSLT engine, this had better be XSLT it's being given. so that would support your point of view on this 15:42:51 <sjoerd_visscher> there are a lot of its 15:42:53 <sbp> we're talking about whether EF document instances can be considered to be XML functions in the http://www.w3.org/DesignIssues/XML sense, or not 15:42:58 <ktest> * ktest thinks he likes XIOR, still trying to connect the dots between it and Ken's reference to OWL by link to "More Toys to Play with" http://www.intertwingly.net/blog/1567.html 15:43:16 <sbp> "it" in there generally refers to an XSLT document instance 15:43:17 <bitsko> a document instance conforming to ER (like atom:feed will be) is not an XML function and is not an exception to the rule. that is to say, one *can* determine what to do with an atom:feed by looking at the namespace of the root element. 15:46:09 <sbp> hmm 15:46:17 <sjoerd_visscher> and that is firing up the aggregator 15:47:56 <bitsko> or transforming to RDF, or styling in the browser, etc. 15:47:59 <sjoerd_visscher> a document instance conforming to ER is useful *before* it is transformed 15:48:44 <sjoerd_visscher> it's main purpose is not providing RDF of being a viewable format 15:48:50 <sbp> (what's ER?) 15:48:51 <sjoerd_visscher> s/of/or/ 15:49:03 <sjoerd_visscher> s/ER/EF/ 15:49:10 <sbp> (ah, thanks) 15:50:23 <sjoerd_visscher> the important point is (I think), when you have an xml file, what is its main purpose, then that's what the rootelement should indicate 15:54:57 <bitsko> I think we may be saying the same thing. it doesn't matter if the root is atom:atom or atom:feed, we know it's an "Atom document" because the root element's namespace *is* the Atom NS 15:55:29 <bitsko> *unlike* XSLT, where the root element's NS *might not* be XSLT, yet the purpose of the XSLT document is for XSLT 15:55:32 <sjoerd_visscher> my point is that EF technology should not look at the atom namespace 15:56:24 <bitsko> ah, that's the "it" I was missing above. I agree. something else says "AtomNS is EF capable". 15:56:46 <bitsko> something else likely == RDDL 15:57:17 <ktest> * ktest thinks RDDL seems a bit excessive, i.e., "crufty" 15:57:24 <sjoerd_visscher> that's fine with me 15:57:48 <sjoerd_visscher> RDDL needs to solve a lot of issues 15:58:03 <sjoerd_visscher> everything wants to be at the end of a namespace 16:01:00 <sjoerd_visscher> sbp, what do you think? 16:01:41 <sbp> I'm not sure. on the one hand, I don't think requiring people to look out to the namespace document is going to be viable all the time 16:02:05 <sbp> so it'd be nice to have the AtomNS as one canonical example of an EF compatible namespace, but then have RDDL for others 16:02:20 <rubys> And a mime type. 16:02:24 <sbp> then people can choose: use the AtomNS if they want to... 16:02:46 <sbp> ah, or a MIME type. hey, I see what MIME types are for now, in conjunction with XML! nasty hacks :-) 16:02:58 <sbp> application/atomef+xml 16:03:57 <sbp> a MIME type is a valid idea. but I'm wondering if the proliferation of EF-type switchers (Atom namespace, RDDL, MIME type) isn't going to cause people to not implement one or two of them 16:04:43 <sbp> practically, it's actually not that hard. you can write a RDDL parser in a few lines, and Content-Type headers should be available easily from most libraries 16:05:07 <sjoerd_visscher> I think RDDL is fine, the application can remember which document types are EF capable 16:05:19 <sbp> but it's the fact that there are *three* ways of finding out whether a document is EF or not that's going to put people off 16:05:34 <sjoerd_visscher> then stick to RDDL 16:05:48 <sbp> I'd possibly prefer a MIME type 16:06:00 <ktest> * ktest re-reads Clay Shirky's criticism: "If you thought that all that was wrong with RSS 1.0 is that RDF didn't make it confusing enough, attach the twin boat-anchors of OWL and the Semantic Web to Echo and see what happens" in http://www.intertwingly.net/wiki/pie/MotivationDiscussion and wonders what "pudding" would "prove" him incorrect? 16:06:12 <sjoerd_visscher> mime type has the same problem as document element namespace 16:06:14 <sbp> but then a MIME type wouldn't be possible where people have subsets of EF, like Atom. Atom is an EF application, basically 16:06:19 <sbp> yeah... 16:06:44 <sjoerd_visscher> application/atom+ef+xml maybe 16:06:53 <sbp> ktest: quite. I guess he was expecting them to be applied brutally and incorrectly? 16:07:10 <sbp> Sjoerd: hmm 16:07:29 <sjoerd_visscher> does rdf do this too? application/rss+rdf+xml? 16:08:13 <rubys> We don't need to completely design this here. RDDL is probably the simplest thing that could possibly work. And sufficient. Of course, people could effectively cache this information (perhaps even by embedding into their application such notions that Atom is AtomEF), making the RDDF effectively optional at runtime. 16:08:35 <sbp> nope. actually, I asked about +rdf on #rdfig once. as someone pointed out, +xml is a syntactic thing--it's telling you that you parse it as a certain syntax to find out the semantics. with +rdf, you'd be telling people the semantics and not the syntax 16:08:42 <rubys> rss 1.0 = application/rdf+xml 16:09:06 <sbp> rdf, not +rdf, note 16:09:57 <sbp> I'm still worried about dispatching 16:10:30 <sbp> but the benefit of not requring a particular namespace on the root element is too much to pass up 16:10:39 <sjoerd_visscher> let's consider a real life example then and see what you'll have to do 16:11:16 <sjoerd_visscher> sbp: in what context are you worried 16:11:45 <bitsko> * bitsko stepped away for a second 16:11:46 <rubys> 99.44% of the time, people will request a GET of an Atom feed, knowing what they are getting is AtomEF compliant, and will not need to have a marker element or to consult with a RDDL 16:12:19 <sbp> I guess I was thinking about applying transformations to see if they fit, but that's a silly idea. so okay, conceded 16:12:25 <bitsko> the use-case for EF to not be tied to the namespace is so that I can create my special PictureFile XML file and use EF to transform it to RDF. without my PictureFile having an atom:atom root element. 16:13:09 <rubys> PictureFile could have an RDDL 16:13:09 <sbp> rubys: reminds me of SGML catalogues. mapping FPIs to DTDs 16:13:27 <sbp> lots of people have local FPI: DTD caches 16:13:37 <bitsko> from a schema perspective, my PF document instance conforms to the schema pattern required by EF. from a processing perspective, EF is no different from XSLT. 16:13:50 <ktest> .acronym FPI 16:13:56 <datum> Fabry-Perot Interferometer, Fast Processor Interface, Federal Prison Industries, Inc., Federal Prison Institute, Field Presence Indicator, Financial Partners Inc., First Patient In (clinical trials), Fishery Products International, Ltd. (Canada), Fixed-Price Incentive (Contract), Floor Plan Identifier, Fluorescent Penetrate Inspection, Food Processing Institute, Foodservice and Packaging Institute, 16:13:59 <datum> Foreign Policy Institute (Paul H. Nitze School of Advanced International Studies, Johns Hopkins University), Formal Public Identifier, Fourier Path Integral (also seen as FOURPI), Freeland Products, Inc. (rebuilder of vacuum power tubes), Front Populaire Ivoirien (Ivorian Popular Front, Ivory Coast), Functional Process Improvement 16:14:28 <sbp> Formal Public Identifier. q.v. http://xml.coverpages.org/tauber-fpi.html 16:15:09 <sjoerd_visscher> so this means prior art with possitive results? 16:15:12 <sbp> it's the thing that looks like "-//W3C//DTD XHTML 1.1//EN" in XHTML 1.1 files, etc. 16:15:58 <ktest> * ktest relieved that it is NOT uber-geek meaning to "out to lunch" 16:16:19 <sbp> just prior art. will be useful for explaining it to some people (e.g. Dave Pawson, who I'm certain has such a catalogue) 16:16:26 <sbp> heh 16:17:11 <sjoerd_visscher> something else: I realised that the id attribute and the href attribute are almost the same thing 16:17:16 <sjoerd_visscher> in EF 16:17:49 <sjoerd_visscher> only id is expecting subelements, and href isn't, but really could 16:18:04 <wkearney> wkearney has joined #echo 16:18:33 <sbp> id is rdf:about, and href is rdf:resource. when an EF document is converted to triples, id is the subject, and href is the object. @href is going to have to be used to sniff for resourceProp elements, so I'm not sure they can be merged into a single attribute 16:18:34 <sjoerd_visscher> compare the link and the generator 16:19:07 <sjoerd_visscher> both create a triple with either id or href as object 16:19:32 <sjoerd_visscher> only when you add subelements does id become the subject 16:20:23 <sbp> ooh, you're right. <feed><link href="URI"/> => _:feed :link <URI> . <feed><generator id="URI"/> => _:feed :generator <URI> . and then uses <URI> as a subject... cool 16:21:10 <sjoerd_visscher> I realised this because XR only has the uri attribute that does both 16:21:14 <bitsko> I recall reading somewhere that the rdf:about/rdf:resource duality was more historical than necessary. if an element has href= *and* has children, it's a resource as well as an object of the parent 16:21:20 <sbp> I don't like "id" and "href", either 16:21:51 <sbp> proposals for what the new universal attribute should be called? 16:22:17 <sjoerd_visscher> in XR <link rdf:resource="" /> becomes <link><rdfs:Resource rdf:about="" /></link> 16:22:29 <sbp> this is good--it draws the amount of special attributes down to two 16:22:41 <sbp> hmm 16:23:03 <sjoerd_visscher> I'm only worried if this works with anonymous resources 16:23:50 <bitsko> I believe that is already in there, as <author> is blank in atom:author 16:24:24 <sbp> I hadn't thought about that before. rdf:resource="URI"> == ><rdf:Description rdf:about=""/> 16:24:35 <sjoerd_visscher> I think it's going to work. XR has strict striping, and the uri attributes are not allowed on property elements 16:25:28 <sbp> I think so too. I'll try updating the XSLT as soon as somebody tells me the new attribute's name :-) 16:25:34 <sjoerd_visscher> ref? 16:25:44 <sbp> any objections to ref? 16:26:07 <sjoerd_visscher> or else uri 16:26:16 <sjoerd_visscher> but ref is nicer to beginners 16:26:23 <sbp> I like @uri... it's what I was using for @href originally 16:26:24 <sbp> yeah 16:26:44 <sbp> bitsko, sam? any preferences? 16:26:49 <sbp> can always swap it about later 16:27:13 <bitsko> uri +1 16:27:17 <sjoerd_visscher> what does this say about XIOR 16:27:29 <bitsko> that's a good q. 16:28:22 <bitsko> the difference I see between EF and XIOR is that xior:xoid is much about identifying root XML fragments, where EF is a striping mechanism 16:28:50 <sjoerd_visscher> maybe it's because programmers think in terms of pointers, instead of node ids that id/ref is always used 16:28:59 <bitsko> in particular, EF supports RDF's concept of a blank node 16:31:41 <rubys> I back. I don't like URI. It doesn't imply a direction. 16:31:56 <bitsko> one could say that since RDF is "ahead" of XML as a higher order data model, and XIOR is a technique for raising the order of XML data model, that using EF "now" is just a matter of picking a data model that exists now. 16:31:59 <sjoerd_visscher> well that's good, because there is no direction 16:32:17 <rubys> sjoerd: what direction to <link> elements point in RSS? 16:32:21 <ktest> * ktest thinks it is more a work in progress 16:32:27 <bitsko> the direction is based on context. 16:32:36 <ktest> http://www.w3.org/TR/rdf-concepts/#dfn-URI-reference 16:32:38 <sbp> yeah. when you have <feed><generator uri="..."><prop>, from the direction of feed, it's an object, from the direction of prop, it's a subject 16:32:40 <rubys> Some would say they identify the item. Some would say they identify what the item refers to. 16:32:49 <sjoerd_visscher> the link is pointing, not the attribute 16:32:56 <rubys> We need two concepts. 16:33:47 <sjoerd_visscher> which two? 16:34:13 <rubys> XOIR calls them xoid and ref... at the moment, the EF calls them id and href. 16:34:26 <rubys> all of these are uri's. 16:34:29 <sjoerd_visscher> not anymore 16:34:46 <sjoerd_visscher> depending on how quick sbp is 16:34:53 <sbp> chuckle. all I did was pretty much convert any instance of @id and @href to @newattr, and it gave me stuff like: <link><rdf:Description rdf:about="http://bob.blog/"/></link> 16:35:09 <sbp> which pretty much shows that yes, rdf:resource is redundant in RDF/XML 16:35:10 <sjoerd_visscher> cool 16:35:48 <bitsko> note: XIOR does not show an example case where a ref and xoid are the same thing. 16:35:51 <sbp> now if I can just get it to tidy that up a bit, it's done 16:36:04 <rubys> what are the new names for these attributes? 16:36:29 <sbp> * sbp wonders to whom that question was addressed 16:36:29 <ktest> * ktest hums the Name Game song 16:36:33 <sjoerd_visscher> there's only one name, temporarily called ref 16:37:04 <imajes> hey sam 16:37:15 <bitsko> it seems @ref was +2 and @uri was +2 16:37:22 <rubys> Atom 0.2 has <link> and <id>. What is being proposed here is that one of them go away? 16:37:34 <bitsko> no! 16:37:39 <sjoerd_visscher> certainly not 16:38:13 <rubys> * rubys is being stalked by James Cox. ;-) 16:38:15 <rubys> Hi James! 16:38:29 <sjoerd_visscher> entry/id becomes entry/@ref and entry/link becomes entry/link/@ref 16:38:53 <bitsko> I see where that confusion came from. <link> is a property that means "the human readable entry in the context of the publisher's site", <id> is a property that means "the unique, permanant identifier of an entry" 16:38:53 <imajes> rubys is not being stalked by me 16:39:12 <imajes> rubys: besides, you didn't link me 16:39:19 <imajes> i can't stalk you incognito 16:39:27 <rubys> just kidding, james. And your page hasn't been updated in a while. 16:39:31 <bitsko> if <id> *weren't* being moved to @id to make EF easier, it would be <link ref="URI"> and <id ref="URI"> 16:39:37 <imajes> rubys: it did today :) 16:39:42 <imajes> rubys: you should take a look 16:39:52 <rubys> cool! MT! 16:39:59 <imajes> indeed 16:40:04 <sjoerd_visscher> link is essentially "the unique, permanant identifier of the human readable representation of an entry" 16:40:23 <bitsko> <link> is not permanent nor unique 16:40:45 <bitsko> in fact, that's why it exists at all ;) 16:40:49 <rubys> link should be permanent, but not necessarily unique 16:40:58 <sjoerd_visscher> the representation is not unique 16:41:03 <bitsko> "should" is the operative word there 16:41:21 <bitsko> sjoerd_visscher: I'm referring specifically to the URI, not the resource representation 16:41:23 <sjoerd_visscher> but link is the unique identifier of the non-unique representation 16:41:51 <NickChalko> NickChalko has joined #echo 16:42:36 <bitsko> link could be "http://foo.org/big_title" until I change it to "http://foo.org/little_title" simply because I changed a title. meanwhile, <id> doesn't change. 16:43:16 <sjoerd_visscher> I understand, read what I said again 16:43:16 <rubys> bitsko, of course, you did code a permanent redirect from big_title to little_tittle, didn't you. ;-) 16:43:40 <sjoerd_visscher> <sjoerd_visscher> link is essentially "the unique, permanant identifier of the human readable representation of an entry" 16:43:50 <bitsko> of course not! I'm a blog author who doesn't believe in cool uris! :D 16:45:17 <rubys> Question: does the EF make *any* XML invalid to use as an extension? 16:47:50 <sjoerd_visscher> It shouldn't 16:48:02 <sbp> some combinations, yes. if you're mixing @ref and @mode. but generally, no. not simple bits of XML 16:48:18 <bitsko> yes. if "arbitrary" XML is included without a mode="xml" 16:48:23 <rubys> <foo mode="george">.... valid or invalid? 16:48:55 <sbp> valid. [] :foo ".... valid or invalid?"^^atom:george at the moment 16:48:55 <bitsko> valid: processing defaults to mode="xml" 16:49:33 <sbp> nope, modes should be extensible 16:49:46 <ktest> .acronym XSL 16:49:47 <sbp> for example, we don't seem to be allowing for base64 at the moment 16:49:48 <datum> eXtensible Stylesheet Language 16:50:12 <sbp> if base64 wasn't in the specification, and one came across <blargh mode="base64">, you can't treat it as something else. it's unknown 16:50:21 <rubys> <foo type="this is not a mime type"> 16:50:29 <sbp> that's invalid 16:50:36 <bitsko> sbp: I'm saying it has to be treated as mode="xml", so that it can be fully captured and propogated. 16:50:55 <sbp> ah, I see. yes, gotcha 16:52:32 <bitsko> re <link>, http://intertwingly.net/wiki/pie/ContentAndPermalink 16:52:57 <sjoerd_visscher> maybe @type has to be renamed to @mime-type? 16:53:08 <bitsko> the <link> URI may not point to a specific entry (not be unique) and may change over time (not be permanent) 16:53:25 <sjoerd_visscher> bitsko: yes, I know 16:53:37 <ktest> http://www.w3.org/TR/rdf-syntax-grammar/ 16:54:08 <rubys> the only way to avoid invalidating something is for the attributes to be in a namespace. That's a tradeoff. My leanings are to accept that some things will be invalid. 16:54:51 <bitsko> rubys: re. ? 16:55:17 <sjoerd_visscher> bitsko: the uri for the link changes when the representation changes, but still link is the unique identifier of the representation 16:55:41 <sjoerd_visscher> bitsko: of the *current* representation 16:56:00 <rubys> if I have an existing namespace that happens to use the attributes 'ref', 'mode', or 'type' in a way that is different than the EF defines, my namespace would be invalid to be used in Atom. 16:56:01 <bitsko> sjoerd_visscher: two <entry>s can have the same <link> URI 16:56:37 <sjoerd_visscher> bitsko: yes, same representation -> same link uri, still link is the unique identifier of the representation 16:57:13 <bitsko> sjoerd_visscher: sure. now I just need to know the relevance of that to <entry><link> 16:58:11 <bitsko> rubys: yes, it would have to be wrapped in an element that has mode="xml" 16:58:23 <sjoerd_visscher> bitsko: I was merely trying to show that it makes sense to have entry/@ref and entry/link/@ref 16:58:55 <rubys> http://diveintomark.org/archives/2003/08/18/atom_api_implementation 16:59:00 <bitsko> sjoerd_visscher: ah. my bad. 16:59:34 <rubys> bitsko: wrapping it as XML misses the point. 16:59:45 <sjoerd_visscher> bitsko: to summarize @ref is a unique property of the link, but the link may change 17:00:05 <anode> anode has joined #echo 17:00:39 <sbp> rubys: actually, not type. type is not part of the EF 17:00:52 <sbp> so only @ref and @mode are considered special 17:01:00 <sbp> which isn't too bad 17:01:18 <sbp> especially now that we're not even requiring the root namespace to be the atom-ns 17:01:34 <sbp> @ref and @mode must surely be considered a significantly low overhead... 17:01:50 <rubys> why isn't type part of the EF? 17:02:34 <sjoerd_visscher> and why can type have influence in creating invalid results? 17:02:38 <sbp> because there's a rule that says when you have @mode and some other attributes on a propElt, it gets converted to [ rdf:value "something"^^{@mode}; other attributs go here ] 17:03:01 <ktest> rubys: re: MP Cool, except I lost him at the authentication part 17:03:06 <bitsko> * bitsko runs to get a burger 17:03:14 <sbp> oh, my mistake. type can't have an influence in creating EF-invalid results. it can have an influence in creating Atom-invalid results 17:03:15 <sjoerd_visscher> sbp: so they are only invalid from the atom viewpoint, not the EF viewpoint 17:03:20 <sbp> right. sorry 17:04:13 <anode> anode has left #echo 17:05:26 <sjoerd_visscher> sbp: about the xsl, you might want to drop the choice, and make separate templates 17:06:07 <ktest> .google XSLT 17:06:08 <datum> XSLT: http://www.w3.org/TR/xslt 17:06:10 <sbp> yeah, I've been thinking about that 17:06:55 <sbp> I'm working on a recursive-descent parser at the moment, though 17:07:43 <sjoerd_visscher> I can do it if you want to, but it's your thing 17:12:38 <sbp> I'm changing the grammar a lot in the process; I wouldn't mind if you want to have a go 17:14:02 <sjoerd_visscher> Ok, I'll take have a go at it later tonight 17:14:33 <sbp> cool. by then, hopefully I'll have a much better grammar for you to follow 17:14:52 <sbp> unless you're working from the XSLT, which would be okay 17:15:10 <sjoerd_visscher> probably both 17:22:09 <sjoerd_visscher> .google ruby 17:22:10 <datum> ruby: http://www.ruby-lang.org/en/ 17:22:43 <sjoerd_visscher> .google sam ruby 17:22:44 <datum> sam ruby: http://www.intertwingly.net/blog/ 17:23:02 <sjoerd_visscher> this is fun 17:23:07 <ktest> .help 17:23:08 <datum> Hi, I'm datum. My owner is AaronSw (Aaron Swartz). 17:23:09 <datum> I sit quietly in various channels until someone types something like: 17:23:10 <datum> ".google secrets of the universe" at which point I respond with the answer. 17:23:11 <datum> Functions include: google, googlecount, time, define, help, acronym, rot13. 17:23:12 <datum> Please contact my owner if there's a problem or you have questions. Thanks! 17:23:43 <sjoerd_visscher> .define 17:24:06 <ktest> .define syllogism 17:24:10 <datum> syllogism is defined as:- 17:24:11 <datum> 1. deductive reasoning in which a conclusion is derived from two premises 17:24:31 <sjoerd_visscher> oh, thanks 17:24:42 <bitsko> sbp: you're editing the grammar on EFG, right? 17:25:04 <sbp> I will be, yep 17:26:26 <ktest> .define complex 17:26:32 <datum> complex is defined as:- 17:26:34 <datum> 1. a conceptual whole made up of complicated and related parts 17:26:34 <datum> 2. a compound described in terms of the central atom to which other atoms are bound or coordinated 17:26:35 <datum> 3. (psychoanalysis) a combination of emotions and impulses that have been rejected from awareness but still influence a person's behavior 17:26:37 <datum> 4. a whole structure (as a building) made up of interconnected or related structures 17:26:39 <datum> 5. complicated in structure; consisting of interconnected parts; "a complex set of variations based on a simple folk melody"; "a complex mass of diverse laws and customs" 17:26:58 <ktest> .define simple 17:27:00 <datum> simple is defined as:- 17:27:01 <datum> 1. (archaic) any herbaceous plant having medicinal properties 17:27:01 <datum> 2. a person lacking intelligence or common sense 17:27:03 <datum> 3. having few parts; not complex or complicated or involved; "a simple problem"; "simple mechanisms"; "a simple design"; "a simple substance" 17:27:05 <datum> 4. easy and not involved or complicated; "an elementary problem in statistics"; "elementary, my dear Watson"; "a simple game"; "found an uncomplicated solution to the problem" 17:27:07 <datum> 5. apart from anything else; without additions or modifications; "only the bare facts"; "shocked by the mere idea"; "the simple passage of time was enough"; "the simple truth" 17:27:08 <datum> 6. exhibiting childlike simplicity and credulity; "childlike trust"; "dewy-eyed innocence"; "simple courtesy" 17:27:09 <datum> 7. lacking mental capacity and devoid of subtlety 17:27:10 <datum> 8. (botany) of leaf shapes; of leaves having no divisions or subdivisions 17:27:12 <datum> 9. not elaborate in style; unornamented; "a simple country schoolhouse"; "her black dress--simple to austerity" 17:27:56 <ktest> .define elegance 17:28:00 <datum> elegance is defined as:- 17:28:01 <datum> 1. a refined quality of gracefulness and good taste 17:30:03 <bitsko> http://diveintomark.org/archives/2003/08/18/atom_api_implementationhttp://diveintomark.org/archives/2003/08/18/atom_api_implementation 17:30:13 <bitsko> oops, http://diveintomark.org/archives/2003/08/18/atom_api_implementation 17:30:25 <bitsko> uses PUT oddly. 17:34:47 <rubys> rubys has joined #echo 17:35:22 <rubys> "uses PUT oddly"... how so? 17:36:15 <rubys> Ah, PUT is supposed to be a replacement, POST is an update. 17:37:48 <bitsko> there were an "XML" range type, one could use PUT with a Range: xml //title 17:38:22 <sjoerd_visscher> but then you couldn't do multiple updates at once 17:38:39 <bitsko> we'd make it up as we go along, of course. 17:38:48 <sjoerd_visscher> is POST better then? 17:39:14 <bitsko> probably for an application-specific use, yes 17:39:31 <bitsko> an IETF/W3C level HTTP Range type for xml would't suck, tho 17:41:11 <bitsko> we'd talked about using the entry-URI as the place to POST comments to. something would have to be clarified there. 17:41:16 <sjoerd_visscher> Mark's solution is rather clean, compared to f.e. XUpdate 17:41:29 <sjoerd_visscher> .google XUpdate 17:41:30 <datum> XUpdate: http://www.xmldb.org/xupdate/ 17:41:49 <bitsko> how does one delete elements using the POST update technique? 17:42:18 <sjoerd_visscher> nice catch 17:42:40 <bitsko> better yet, how does one know whether one is replacing or updating one property of an <entry><author><name> 17:42:56 <sjoerd_visscher> there are not even workarounds for that 17:42:59 <bitsko> is that replacing <author> with a corrected version, or updating <author><name> 17:43:18 <sjoerd_visscher> adding a ref would help there 17:43:43 <sjoerd_visscher> no it doesn't 17:46:40 <bitsko> I suspect that updating a resource in-place is a non-trivial operation. 17:48:00 <sjoerd_visscher> adding and removing contricutors later is rather likely to occur from time to time 17:48:08 <sjoerd_visscher> contributors 17:48:32 <sillygwailo> sillygwailo has joined #echo 17:49:31 <bitsko> I had a discussion with someone (forgetting who, now) on #joiito about updates. they made a couple of claims, 17:50:15 <bitsko> 1) Range: bytes was acceptable for all Content-Types, because by definition all HTTP entity resources are capable of being represented by octets. 17:50:36 <bitsko> 2) Range: xml was not acceptable because it was not generic for all Content-Types. 17:51:28 <bitsko> I disagree with both claims, natch ;) 17:53:30 <sjoerd_visscher> bitsko: +1 17:53:44 <bitsko> Range is technically Content-Range 17:55:59 <bitsko> logecho, bookmark? 17:55:59 <logecho> See http://bitsko.slc.ut.us/chatlogs/echo/2003-08-18#T17-55-59 17:57:10 <emanu> emanu has joined #echo 18:07:25 <sjoerd_visscher> sjoerd_visscher has left #echo 18:07:51 <rubys> http://bitworking.org/news/Working_AtomAPI_Implemenation#X1 18:12:06 <rubys> http://www.intertwingly.net/wiki/pie/ExtensibilityFramework still reflects last night's use of attributes. 18:12:47 <imajes_> imajes_ has joined #echo 18:14:59 <burtonator> burtonator has joined #echo 18:20:11 <Sjoerd_> Sjoerd_ has joined #echo 18:27:53 <rubys> Is the consensus that the outer atom:atom element is necessary or not? 18:31:36 <rubys> I've updated ExtensibilityFramework to be consistent with ExtensibilityFrameworkGrammar 18:32:48 <bitsko> I see no reason for atom:atom 18:32:49 <sbp> thank you. I've updated ExtensibilityFrameworkGrammar to use a much simplified but more precise grammar. the instructions mimic the working SAX recursive-descent parser that I just wrote, and will be publishing shortly 18:33:42 <sbp> currently, any element can be used as the root element, but there has to be *an* element there of some sort 18:34:19 <rubys> * rubys tingles with anticipation 18:34:22 <bitsko> I think EFG now says no atom:atom 18:34:41 <bitsko> or, "what sbp said" ;) 18:35:56 <sbp> http://infomesh.net/2003/atomef/atomef.py.txt 18:36:05 <sbp> bitsko will recognize the guts of the code :-) 18:36:17 <sbp> (it's converted from an RDF/XML parser) 18:36:27 <sbp> not bad: 7.10KB 18:36:50 <sbp> and it's SAX independent, too. I could use Python's xmllib if I wrote another class 18:37:19 <rubys> * rubys mutters "GPL" 18:37:25 <sbp> whoops: the subject=None bits are redundant 18:37:40 <sbp> is GPL not acceptiable for you? what license would you like? LGPL? 18:37:44 <rubys> Python 18:38:19 <rubys> is the code that you based this on GPL? 18:38:21 <sbp> * sbp updates the cleaner version 18:38:33 <sbp> it is. is the Python license not GPL compatible, though? 18:38:41 <sbp> s/the/to the/ 18:39:05 <rubys> Compatible, yes. 18:39:18 <sbp> okay. I can release a version of this under the Python license, then 18:39:50 <rubys> You can use Python code in commercial (non-free) products and in GPL licensed code. 18:41:18 <sbp> how would you like me to go about this? I can say "released under a GPL or Python 2.2 per user-choice" or somesuch 18:41:49 <sbp> er, viz. "released under a GPL " or Python 2.2 license per user-choice" 18:41:50 <rubys> Simply release it under Python's license. Python is GPL compatible. 18:42:29 <rubys> The question is whether you want to enable "exploitation" by others that may not chose to contribute back. 18:43:12 <rubys> I'm more of the ASF/BSD persuasion: don't pass off my work as your own, but other than that do what you want with it. Just don't sue me. 18:43:49 <sbp> me too, though I tend to like the slightly stricter license when looseness is not specifically required 18:44:04 <sbp> I'm not advese to it for EF code, hence refresh 18:44:15 <sbp> s/advese/adverse/ 18:45:36 <Sjoerd_> I wasn't paying attention. Explain why *an* extra element is still required 18:47:37 <rubys> I just ran atomef.py against the example in the ExtensibilityFramework, but I don't understand the output. 18:48:09 <rubys> The first line of output is as follows: 18:48:11 <rubys> http://purl.org/atom/ns#title http://purl.org/atom/ns#link http://purl.org/atom/ns#modified http://purl.org/atom/ns#author http://purl.org/atom/ns#name http://purl.org/atom/ns#generator http://purl.org/atom/ns#name http://purl.org/atom/ns#entry http://purl.org/atom/ns#title http://purl.org/atom/ns#link http://purl.org/atom/ns#issued http://purl.org/atom/ns#modified http://purl.org/atom/ns#content None <http://purl.org/atom/ns#title> "Bob's Blog" . 18:49:18 <sbp> hmm 18:50:00 <sbp> my fault. there was a print debugging statement left in 18:50:02 <sbp> updated 18:50:27 <sbp> should start like this, now: [[[ 18:50:27 <sbp> _:id0 <http://purl.org/atom/ns#title> "Bob's Blog" . 18:50:27 <sbp> _:id0 <http://purl.org/atom/ns#link> <http://bob.blog/> . 18:50:27 <sbp> _:id0 <http://purl.org/atom/ns#modified> "2003-08-17T18:30:00Z" . 18:50:28 <sbp> ]]] 18:52:18 <sbp> Sjoerd: otherwise you'd only have one propertyElt per document 18:53:24 <Sjoerd_> sbp: so feed is the rootelement? 18:53:52 <sbp> at the moment, feed can't be a rootelement 18:54:17 <Sjoerd_> that's what I don't understand 18:54:24 <sbp> if feed were a root element, you'd have one property per document. though you could get around that by chaining, I guess 18:54:57 <rubys> why would you have one property per document? 18:54:59 <Sjoerd_> how so, each child element of feed as a property 18:55:09 <Sjoerd_> s/as/is/ 18:55:17 <sbp> what if, as bitsko's been thinking, you want to have authors and entries etc. in documents standing alone? 18:55:38 <sbp> then they'd be related to the feed root 18:55:55 <sbp> what if I want an author or some thing which isn't related to the root element? 18:55:56 <Sjoerd_> ah, you don't need to 18:56:11 <sbp> if the root element were a propertyElt, how could I put things in the document which weren't related to it? 18:56:41 <Sjoerd_> you can't, except for creating a new document 18:56:44 <sbp> you don't need to for Atom 0.2. you may need to for Atom in the future 18:56:48 <sbp> right 18:57:17 <sbp> so it's for the case when you want to start a new thing in the document. it allows new entities which aren't related to anything else 18:57:19 <Sjoerd_> the author shortcut could be done that way 18:57:28 <sbp> yep 18:58:59 <bear_> bear_ has joined #echo 18:59:27 <Sjoerd_> I don't think we should go there 19:00:05 <sbp> it'll make it more reusable. and it'll allow for extensions to Atom in future 19:01:48 <Sjoerd_> very similar to rdf 19:02:11 <rubys> Now my first line looks like: 19:02:12 <rubys> None <http://purl.org/atom/ns#title> "Bob's Blog" . 19:02:25 <rubys> ... but then again, my first line of the input is <feed>. ;-) 19:02:49 <sbp> ah, yes. you need to wrap with <atom> 19:03:06 <rubys> I'm with Sjoerd. I shouldn't have to. 19:03:18 <bitsko> bitsko has joined #echo 19:03:21 <Sjoerd_> interesting that it still figured out it had to be a property 19:03:26 <f8dy_away_> f8dy_away_ has joined #echo 19:03:32 <sbp> there are only properties 19:03:32 <Hat_> Hat_ has joined #echo 19:03:47 <Sjoerd_> ah, feed is a property of none? 19:03:49 <danja> danja has joined #echo 19:03:52 <sbp> hmm. it's odd that it used title, though; it should dispense 19:04:28 <sbp> * sbp tests 19:05:25 <sbp> yeah, I get the same. it's just an error: using feed as the root isn't accounted for at all, and <property>#PCDATA</property> is undefined when there's no current subject 19:06:01 <sbp> I can update it to use the root as a propertyElt if you like 19:06:15 <bitsko> I misread then. I'm still -1 on a root wrapper element. 19:06:29 <bitsko> I see it basically as a design decision: do we allow multiple top-level resource elements in a document or do we restrict a document to a single root resource element. there's little technical reason that I see to choose one over the other. 19:06:35 <bitsko> Atom to this point has had a single root resource element and EF allows multiple root resource elements. just a design decision difference. 19:06:48 <sbp> yep 19:06:52 <bitsko> last msg I saw was <Sjoerd_> that's what I don't understand before seeing <Sjoerd_> interesting that it still figured out it had to be a property 19:07:10 <sbp> but what about your case of wanting to include multiple entities in a document? entities of sorts other than feed, perhaps 19:10:23 <sbp> okay, I've updated the SAX parser 19:10:25 <sbp> grammar to follow... 19:11:36 <rubys> TypeError: unsupported operand type(s) for +: 'NoneType' and 'unicode' 19:11:42 <rubys> File "atomef.py.txt", line 86, in __init__ 19:11:42 <rubys> self.URI = xmlns + name 19:12:25 <sbp> not sure why you're getting that error, but I'll fix it anyway... 19:12:31 <rubys> FYI: that was with a dummy element I inserted for testing. That dummy element didn't have a namespace. 19:12:44 <sbp> ah, I see. that'd be invalud 19:12:44 <rubys> Removing that dummy element, and the results make sense. 19:12:46 <sbp> er, invalid 19:12:56 <rubys> _:id0 <http://purl.org/atom/ns#title> "Bob's Blog" . 19:13:14 <sbp> grammar's been updated. EF example to follow 19:13:25 <sbp> oh 19:13:35 <sbp> heh, it's already been done. thanks Sam, presumably 19:14:03 <rubys> What would this output look like in RDF/XML? 19:15:53 <sbp> argh. I'm not sure since my *($%!)&U£% converter doesn't handle datatypes properly. but basically, it should be much like the XSLT output 19:16:36 <sbp> one could write a sink to convert to RDF/XML 19:16:43 <rubys> The XSLT output uses structure. I would presume that there would be a cannonical form for linear triples. 19:16:50 <sbp> or update the XSLT... 19:17:13 <sbp> it depends upon your triples => RDF/XML converter. I believe that Dave Beckett has a great one in Perl 19:17:36 <Sjoerd_> anybody working on ExtensibilityFramework? 19:17:58 <Sjoerd_> the @href on the link on feed must be @ref 19:17:59 <danja> ah - good question - Atom -EF-> NTriples? 19:18:30 <rubys> Danny! 19:18:37 <sbp> I'm not. I can update it, though 19:18:54 <rubys> Danny: http://infomesh.net/2003/atomef/atomef.py.txt 19:19:01 <sbp> done 19:23:26 <danja> thankyou! 19:24:10 <danja> * danja hunts for his Python 19:24:27 <f8dy> * f8dy likes that mental image 19:25:00 <sbp> it'll probably require 2.2 upwards 19:25:19 <danja> miraculously that's what I've got 19:26:11 <Sjoerd_> sbp: I'm starting to make the XSL 19:26:30 <Sjoerd_> what do you do with attributes? 19:26:32 <sbp> ooh, thanks Sjoerd 19:26:41 <sbp> do with them at what point? 19:27:07 <Sjoerd_> f.e. <entry bla="foo">...</entry> 19:27:34 <Sjoerd_> does this generate a bla property? 19:28:09 <sbp> nope. undefined at the moment 19:28:20 <sbp> except on complexLiteral 19:28:48 <Sjoerd_> EF could do that right? 19:28:49 <sbp> on complexLiteral it does indeed: you create a blank node, and then hang [ :bla "foo" ] off of it 19:28:56 <sbp> it could do, yes 19:29:19 <sbp> there are a few possibilities for extensions like that that Atom won't use but other syntaxes might want to 19:31:34 <yining> yining has joined #echo 19:32:04 <rubys> it looks to me like you support it on literalProp too, or am I misunderstanding? 19:32:39 <rubys> @mode='xml', @type="text/plain" 19:33:22 <sbp> @type isn't allowed on literalProp: a property with an @type must be a complexLiteralProp 19:33:32 <sbp> @mode is allowed since it's one of the two special attributes 19:33:52 <sbp> that way, <title mode="encoded">blargh is just a literalProp 19:34:40 what is blargh ? 19:35:59 I presume it also is just a literalProp? 19:36:00 it gets converted to "blargh"^^atom:string at the moment. it could feasibly become "blargh", but we've got a no-defaulting/interpreting/interfering rule. cf. mine and bitsko's lengthy conversation last night 19:36:11 oh, what production? yes. literalProp 19:36:20 anything with just a mode is a literalProp 19:36:33 xian has joined #echo 19:37:59 * sbp wonders when Aaron gets back 19:41:16 sbp: why not drop a link to your parser on the wiki? 19:41:33 whoops, good point. adding 19:44:55 done 19:54:38 bitsko: excellent response to Tim Bray on the mailing list 19:55:32 FYI: I'm planning on going the the hackathon at Seybold. 19:55:33 ta 19:55:42 * bitsko jealous! 19:57:53 Round trip MSP=>SJC: $273 19:58:19 now i need to catch up on the mailing list - what's its URL again? 19:58:24 when's the hack-a-thon? 19:58:44 someone needs to set up a seybold trackback weblog this year 19:59:27 http://www.imc.org/atom-syntax/mail-archive/maillist.html 20:01:45 we should probably also plan a dinner or two. 20:05:08 that would be nice. i guess i need to post the holes in my schedule and invite people to set up ad hoc meetings 20:12:56 Sjoerd: if you're around, minor change to the grammar, in the property test (test for simpleProp) region. Python/SAX updated too 20:13:05 ok 20:13:25 first version of the xslt is just finished, I was about to test it 20:13:31 ooh, excellent 20:13:42 dinner - mmm - time to eat, 20:14:04 what was there previously worked on the current test case, but wouldn't work for something more general 20:14:26 should xml:lang be a special attribute too? 20:15:53 I'm not sure about that. there's a current big debate in the RDFCore world as to whether datatypes and languages can be allowed together on literals. that's why I moved xml:lang to the XML content--and it works nice that way too 20:16:25 imajes has joined #echo 20:16:25 but I have a feeling that it's going to be reinstated on content, and therefore yes, it'll have to be treated as a special attribute 20:16:30 it seems like another case like author: specifying it once at the top may make sense for a lot of weblogs 20:17:02 yeah 20:17:13 xml:base is another one that'll have to be treated as special 20:17:19 in fact, anything from xml:* 20:25:48 could we say, for the EF but not Atom's EF implementation, that when atom:atom specifically is used as the root node, you ignore it and start by processing each of its children elements as propertyElts? 20:25:53 the 3 templates for the 3 types of properties are easy, but the @match xpaths are horrible 20:48:40 yeah, it's not surprising. that's why I did an @match on everything and then restored to tests 20:48:51 s/restored/resorted/ 20:49:20 is there an EF valid xml example online? 20:50:10 there is now: http://infomesh.net/2003/atomef/atom.txt 20:50:20 the one in wiki:EF is valid, too 20:50:46 the atom element isn't there 20:51:09 yeah. Sam removed it, and bitsko indicated he wanted it gone, too 20:51:13 I think it should be optional 20:51:24 check out ExtensibilityFrameworkGrammar 20:51:28 currently, document := property 20:51:42 it used to be document := property* 20:51:58 I'd like it to be document := property* | property 20:52:26 would that be acceptable? 20:52:35 the xsl can do that 20:52:43 it's the best of both worlds isn't it 20:52:45 excellent. I'll update 20:52:49 yep. that's what I thought 20:56:38 okay, updated the Python/SAX and ExtensibilityFrameworkGrammar 20:56:46 dajobe has joined #echo 20:57:12 or <*:*> property* | property 20:57:28 http://w3future.com/2003/atomef/atomToRDF.xsl 20:57:32 * bitsko continues to push on removing *anything* atom-specific 20:57:47 you can't differentiate between those 20:58:01 the rdf the xsl generates isn't valid yet 20:58:30 I'm confused when and how to use rdf:parseType=Literal and rdf:datatype 20:58:38 have the root node create a useless blank node with the top-nodes as properties. 20:59:13 ouch: *[@ref][not(node())] | *[*][not(@*)] | *[*][@ref][count(@*)=1] 21:00:03 for literalProp:- 21:00:18 * if there's no mode and no children, the result is "blargh" 21:00:50 * if there are children elements or @mode='xml', the result is "blargh"^^rdf:XMLLiteral (so use rdf:parseType="Literal") 21:01:28 * if @mode!='xml', the result is "blargh"^^atom:{@mode} (so use rdf:datatype="...atom/ns#{@mode}") 21:01:50 rdf:datatype automatically means parseType=Literal? 21:01:56 no 21:02:20 nope. rdf:parseType="Literal" automatically means ^^rdf:XMLLiteral, AFAIK 21:02:23 pT=L lets you have XML values inline 21:02:31 and implies a datatype 21:02:38 rdf:datatype just gives you the datatype URI. 21:02:51 if you wanted xml, you'd have to escape all that <foo> etc. 21:03:00 a, I see 21:03:26 dajobe: have you been following? 21:03:35 the megabytes of chat, no 21:03:45 * sbp is relieved 21:04:05 the rdf word seems to come up a lot for an #echo channel :P 21:04:41 yeah... we're trying to map it to RDF without changing the syntax 21:05:03 ...by creating an alternate RDF serialization... 21:05:19 much like designissues's Syntax, or Melnik's proposal 21:05:20 yet another 21:05:23 yeah 21:05:33 http://www.intertwingly.net/wiki/pie/ExtensibilityFrameworkGrammar 21:05:49 grammar style cribbed from RDF/XML, except it's not as rigourously defined yet 21:05:51 why not just write the triples for whatever echo's XML looks like 21:06:43 http://infomesh.net/2003/atomef/atom.txt => http://infomesh.net/2003/atomef/atom.nt.txt 21:06:51 inventing 2 new syntaxes seems a bit daft 21:07:04 2 new ones? there's only one 21:07:43 ...by creating an alternate RDF serialization... 21:07:46 dajobe: the problem is that echo's XML is extensible, which means a generic transform can't be developed without setting a style guide. the ExtensibilityFramework is that style guide. 21:08:01 good luck 21:08:33 thx, I think ;) 21:09:07 so a new syntax, a new xml schema language and a mapping to rdf. You'll need luck ! 21:09:23 a new xml schema language?! where? 21:09:47 oh, right, in EFG. that's just a draft 21:10:20 bnf for an xml syntax - danger, that's where rdf/xml-99 went wrong 21:10:26 I see the same issues there 21:10:50 can you elaborate? 21:10:53 hmm. I was planning on just doing whatever the current RDF/XML syntax grammar does 21:11:17 I'd have to decode your notation 21:11:19 the current does a lot more than this 21:11:27 but it seems you have 4-5 empty element forms that are all ambiguous 21:12:05 RelaxNG would work much better here I think 21:12:07 working with such low level xml gets you in holes like that 21:12:19 ye 21:12:21 yes 21:12:32 anyway, that's just my experience 21:12:53 relaxng has the advantages of a (genius) designer and running code 21:13:19 so sbp, what did the atom.txt->.nt mapping? 21:13:30 this parser: http://infomesh.net/2003/atomef/atomef.py.txt 21:14:10 so the mapping is in the code? 21:14:27 yes. the specification isn't compilable yet :-) 21:15:34 I think Knuth's working on something like that... 21:16:09 I'll wait till it's written down as text 21:16:17 btw you need to do xml escaping properly 21:16:21 yes. I think that's a good idea 21:16:25 "Atom Updates & Ideas" 21:17:43 Atom Updates &amp; Ideas => atom:title "Atom Updates & Ideas"^^ 21:18:29 ? 21:18:36 sbp: I see no triple with _id2 as object in atom.nt.txt 21:18:37 in the n-triples, the bare & must be & 21:18:59 hmm 21:19:47 dajobe: why is that? 21:20:20 should " then be " instead of \" ? 21:21:06 it's xml canonicalization 21:21:06 Sjoerd: fixed atomef.py.txt and atom.nt.txt 21:21:34 I think " yes, I wrote it once and now I don't recall 21:21:55 seems not 21:22:01 only <, > and & 21:22:08 xml is SO dull! 21:23:03 feeding Atom Updates &amp; Ideas to the RDF validator gives me "Atom Updates & Ideas" as the object of the output triple 21:23:03 xml defines 5. 21:23:22 < > & " ' 21:23:23 That's not XML content with rdf:parseType="Literal" 21:23:31 it's a unicode string 21:23:45 right. same with 21:24:13 <sbp> to make it like rdf:parseType="Literal", you need to use @mode="xml" 21:27:02 <sbp> @mode is like @rdf:datatype, but 'xml' maps to rdf:XMLLiteral, and all other values map to atom:{@mode} 21:28:18 <Sjoerd_> http://w3future.com/2003/atomef/atom.nt.html 21:28:29 <Sjoerd_> sbp: I think we have the same triples now 21:29:19 <sbp> Sjoerd: yes! excellent 21:29:27 <sbp> this is output from your atomToRDF.xsl, yes? 21:29:45 <Sjoerd_> yes, through the rdf validator 21:29:59 <sbp> excellent. mind if I link from the wiki? 21:30:17 <Sjoerd_> what do you think 21:31:08 <sbp> heh. okay 21:31:08 <Sjoerd_> * Sjoerd_ would have put up big warning signs if not 21:34:38 <sbp> added a link. thank you 21:35:51 <Sjoerd_> thank you for calling it excellent 21:37:11 <shawn_> shawn_ has joined #echo 21:37:41 <rubys> do we anticipate major changes? 21:37:44 <KevinMarks> sorry for renaming noise 21:38:16 <Sjoerd_> for EF or atom in general? 21:38:17 <rubys> If we are at a stable point... perhaps it is time for wider feedback? 21:38:21 <rubys> for EF. 21:39:11 <Sjoerd_> the only problem is still see is: match="*[@ref][not(node())] | *[*][not(@*)] | *[*][@ref][count(@*)=1]" 21:39:56 <Sjoerd_> I wish that could be simpler 21:41:12 <bitsko> Sjoerd_: translate to human, if you can? 21:42:08 <Sjoerd_> from EFG: 01 If the element has children or @ref, and there are no @mode or non-special attributes, then it is a simpleProp. 21:42:37 <sbp> the Python that I transcribed that from:- 21:42:37 <sbp> if ((e.children or e.attrs.has_key('ref')) and 21:42:38 <sbp> not e.attrs.has_key('mode')): 21:43:23 <sbp> it is a bit complex. perhaps we could match for literalProp first, then complexLiteral, then simpleProp. would that help? 21:43:35 <Sjoerd_> maybe 21:45:06 <Sjoerd_> that would be *[count(@mode)=count(@*)] 21:45:20 <Sjoerd_> which I already have 21:46:02 <Sjoerd_> no,not enough 21:46:39 <Sjoerd_> *[count(@mode)=count(@*)] [not(*)] 21:46:49 <sbp> yeah. that's what I've just got: if not attrs and (e.attrs.has_key('mode') or not e.children): 21:48:20 <sbp> then the rest seems like it might be:- 21:48:20 <sbp> elif attrs: self.complexLiteralProp(e) 21:48:21 <sbp> else: self.simpleProp(e) 21:48:36 <sbp> which is rather simple 21:48:48 <Sjoerd_> so literalProp is *[count(@mode)=count(@*)] [not(*) or @mode] 21:49:18 <sbp> yes, I think 21:49:19 <Sjoerd_> ok let's do that 21:50:07 <sbp> so, in prose: "If there are no ''special-attrs'' and either an @mode or no children, then it's a literalProp. Else if there are ''non-special'' attributes, it's a complexLiteralProp. Otherwise it's a simpleProp." 21:50:46 <sbp> sigh. doesn't work 21:51:17 <sbp> <something @ref="..."/> gets picked up as a literal 21:51:48 <Sjoerd_> elif attrs and not(@ref) 21:52:07 <sbp> nope, picked up as a literal, not complexLiteral 21:52:30 <sbp> so it'd need to be "if not attrs and note.attrs.has_key('ref') and (e.attrs.has_key('mode') or not e.children): ", I think 21:52:37 <sbp> s/note/not e/ 21:52:55 <sbp> which is fast becoming as nightmarish as the old method 21:53:09 <Sjoerd_> not for xsl, I already had that 21:53:27 <Sjoerd_> count(@mode)=count(@*) doesn't allow @ref 21:53:33 <sbp> ahh 21:53:43 <sbp> okay, the Python works, and it's not too bad 21:53:43 <sbp> if ((not attrs) and not e.attrs.has_key('ref') and 21:53:44 <sbp> (e.attrs.has_key('mode') or not e.children)): 21:54:12 <sbp> prose: "If there are no ''non-special'' and no @ref and either an @mode or no children, then it's a literalProp. Else if there are ''non-special'' attributes, it's a complexLiteralProp. Otherwise it's a simpleProp." 21:54:23 <imajes_> imajes_ has joined #echo 21:54:27 <sbp> whoops, no ''non-special'' attrs 21:55:32 <Sjoerd_> and children is child-elements 21:55:43 <sbp> yep. sorry. adding to EFG 21:56:46 <sbp> okay, done. all happy? 21:56:59 <bitsko> * bitsko rereads EFG 21:57:28 <sbp> updated atomef.py.txt 21:57:29 <Sjoerd_> xsl is working too 21:57:40 <sbp> excellent 21:57:56 <sbp> certainly looks neater now that that large path is gone 21:58:13 <Sjoerd_> paths are still long, but more readable 21:58:17 <sbp> the other approach is valid still, of course 21:59:31 <Sjoerd_> hopefully equivalent 21:59:46 <sbp> yes; I've checked the outputs with diff 21:59:57 <dajobe> at least http://w3future.com/2003/atomef/atom.nt.html you need <> around the uris for datatypes ^^<uri-here> 22:00:18 <dajobe> maybe that's just detail 22:00:35 <sbp> it'd be nice to have <> around the URIs and _: in front of the bNodes, too 22:00:51 <dajobe> that'll make it n-triples 22:00:53 <sbp> s/genid:/_:/ 22:01:13 <Sjoerd_> that's what the RDF validator generates 22:01:22 <sbp> ahh 22:01:25 <dajobe> click the n-triples button 22:02:24 <dajobe> anyway, if you've got that far, you must be making something ok 22:03:00 <bitsko> :) 22:03:01 <sbp> thanks! it's difficult trying to keep it simple whilst accomodating for Atom and all the while maintaining a nice RDF model... 22:03:31 <Sjoerd_> n-triples feature is broken 22:03:43 <Sjoerd_> it's doesn't escape the literals 22:04:25 <bitsko> if <feed> had a @ref, that'd work, correct? 22:04:52 <sbp> yes, that'd be fine. it'd give you <{@ref}> instead of _:id0 in the NTriples 22:05:02 <bitsko> coolio. 22:05:27 <bitsko> I think that should be encouraged, esp. wrt. foaf:weblog 22:05:48 <sbp> good point 22:06:12 <Sjoerd_> who can easily set up a foaf file in EF format? 22:06:19 <sbp> I've already written one 22:06:26 <Sjoerd_> let's try it then 22:06:48 <sbp> uploading. it was written a while ago; I hope it still works 22:07:02 <sbp> http://infomesh.net/2003/atomef/foaf.atom.txt 22:07:44 <Sjoerd_> whoa 22:07:52 <dajobe> I'm not going near that 22:07:55 <bitsko> heh. re EF'ing FOAF, we shouldn't go there 22:08:03 <dajobe> atom's not going to be an alternative rdf xml syntax 22:08:13 <dajobe> let atom stick with it's goals 22:08:14 <sbp> * sbp deletes it for the time being 22:08:20 <Sjoerd_> my result is: 10 pages of namespaces 22:08:43 <bitsko> as soon as I got to <foaf:knows><foaf:Person><foaf:name>, I realized the error there. 22:08:44 <sbp> my result was... interesting 22:09:31 <sbp> oh, it uses id and href, that's why 22:11:10 <sbp> works fantastically now 22:11:32 <sbp> uploaded the new version in case you want to test it, Sjoerd 22:12:05 <sbp> * sbp is rather pleased with that 22:12:48 <Sjoerd_> I've got 69 triples 22:12:58 <bitsko> so it's still pulling the rdf:type from top-level elements, as a feature? 22:13:33 <Sjoerd_> the xsl doesn't 22:13:57 <dajobe> sbp: what did you change? 22:14:05 <dajobe> ... what url ... 22:14:30 <sbp> $ ./atomef.py.txt foaf.atom.txt | wc -l 22:14:30 <sbp> 69 22:14:38 <Sjoerd_> yes! 22:14:41 <sbp> mine doesn't pull rdf:type either 22:14:50 <sbp> dajobe: http://infomesh.net/2003/atomef/foaf.atom.txt 22:15:03 <Sjoerd_> you won't believe the rdf/xml it generates: 12http://www.w3.org/2000/06/webdata/xsl12t?xslfile=http%3A%2F%2Fw3future.com%2F200312%2Fatomef%2FatomToRDF.xsl&xmlfile=http%3A12%2F%2Finfomesh.net%2F2003%2Fatomef%2Ffo12af.atom.txt&transform=Submit01 22:15:07 <dajobe> you see why I made sure ntriples remained line based now ? 22:15:17 <sbp> at the moment it just loses it; I should update the FOAF to use rdf:type 22:15:24 <sbp> dajobe: yes! thank you. works with unix tools 22:15:58 <sbp> Sjoerd: I know... I downloaded your XSLT and ran it through saxon. I pasted the results in the RDF Validator, though, and look at the graph: http://www.w3.org/RDF/Validator/ARPServlet.tmp/servlet_3349.png 22:16:00 <Sjoerd_> sbp: simonstl has to see your foaf 22:16:03 <sbp> the graph looks fine to me 22:16:04 <sbp> heh, heh 22:16:19 <Sjoerd_> it's a problem with the namespaces, I can fix that 22:16:28 <dajobe> things he hates 1) namespaces 2) rdf 3) see 1 & 2 22:16:41 <Sjoerd_> I had the same with XR 22:16:54 <dajobe> oh I missed 4) uris 22:17:03 <sbp> it also gave "Error: {W130} Base URI is "", relative URIs left as relative.[Line = 2, Column = 794]", BTW 22:17:17 <sbp> heh, yeah. did you see his FOAF recasting, by any chance? 22:17:34 <rubys> http://www.simonstl.com/projects/foaf-xml/ 22:17:34 <dajobe> yeah, I forgt the details 22:17:40 <dajobe> yet another xml format 22:17:43 <sbp> yeah 22:18:38 <dajobe> remember xml is dull, only write the minimum number of parsers, scrapers, xslt, ... you ever need so you can get to the interesting stuff - apps 22:18:58 <sbp> +1 22:19:41 <rubys> the flip side of that is that abstractions leak. Avoid using layers of software that obscure. 22:20:04 <bitsko> http://bitsko.slc.ut.us/~ken/foaf.ef 22:20:13 <rubys> Show of hands: how many people here use IDEs? 22:20:19 <dajobe> emacs? 22:20:25 <bitsko> emacs 22:20:38 <Sjoerd_> not even emacs 22:20:41 <rubys> vi 22:21:18 <dajobe> well, I'm using vi and emacs right now but of the two I know which one's nearer an IDE 22:21:25 <rubys> neither 22:21:59 <bitsko> I've heard one can use emacs as an ide... ;) 22:23:47 <Sjoerd_> the w3c xslt servlet doesn't chokes on <xsl:copy-of select="namespace::*" /> 22:23:58 <Sjoerd_> anybody has any idea what's wrong with that? 22:24:17 <Sjoerd_> it works in XML::LibXSLT 22:24:30 <sbp> bitsko: nice consistent triples from your FOAF file 22:24:37 <sbp> Sjoerd: all I know is that it uses Java... 22:25:17 <bitsko> sbp: did the rdf:type come thru? I notice it's <rdf:type><rdf:Description rdf:about="..."> 22:25:26 <sbp> it did indeed 22:25:37 <sbp> first two triples generated:- 22:25:38 <sbp> _:id0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Person> . 22:25:38 <sbp> _:id0 <http://xmlns.com/foaf/0.1/name> "Ken MacLeod" . 22:26:03 <sbp> and the above RDF/XML works... 22:26:14 <sbp> (and proves, possibly, that rdf:resource is redundant) 22:27:12 <bitsko> sbp: I'd read somewhere that rdf:resource is redundant. it was in a text describing rdf:ID, I think. 22:27:35 <sbp> interesting 22:27:54 <Sjoerd_> rdf:ID is also redundant I think 22:27:59 <bitsko> I think danbri mentioned it 22:29:21 <dajobe> rdf:resource is sort of redundant 22:29:29 <dajobe> but you really don't want to do that 22:29:36 <dajobe> see sec 2 of rdf/xml syntax for the details 22:30:28 <sbp> heh. check out "Allow Attributes" in http://logicerror.com/rdf-syntax-idea - spooky. and the parseType="resourceURI" idea, too 22:30:33 <sbp> * sbp reads RDF/XML Syntax sec 2 22:30:54 <Sjoerd_> dajobe: maybe you can point to a specific part of sec.2 22:31:19 <Sjoerd_> 2.4? 22:31:24 <dajobe> well, see fexample 2 22:31:26 <dajobe> there is no resource there 22:31:35 <sbp> 2.4 Empty Property Elements, I'm guessing 22:31:43 <dajobe> yes 2.4 is equiv 22:32:20 <dajobe> btw all the rdf/xml examples are there hidden http://www.w3.org/TR/rdf-syntax-grammar/example04.rdf 22:32:26 <dajobe> and ntriples. 22:32:35 <dajobe> I wasn't shipping anything without machine checked examples 22:32:40 <Sjoerd_> so basically only because it's longer? 22:32:46 <sbp> because we've currently got one attribute doing the work of about/resource, it's natural for us to map onto <prop><rdf:Description rdf:about="URI"/></prop>, it seems (that's how Sjoerd's XSLT does it). but I added a little bit into my XSLT a while ago to output rdf:resource where it can 22:32:48 <dajobe> longer - yes 22:34:08 <Sjoerd_> <xsl:template match="@ref"> 22:34:09 <Sjoerd_> <xsl:attribute name="rdf:about"><xsl:value-of select="." /></xsl:attribute> 22:34:09 <Sjoerd_> </xsl:template> 22:34:29 <Sjoerd_> it does make the xslt a lot more elegant 22:36:10 <Sjoerd_> ok, fixed 22:36:18 <Sjoerd_> I only added 22:36:19 <Sjoerd_> <xsl:template match="*[@ref][not(node())]" mode="object"> 22:36:20 <Sjoerd_> <xsl:attribute name="rdf:resource"><xsl:value-of select="@ref" /></xsl:attribute> 22:36:20 <Sjoerd_> </xsl:template> 22:36:26 <Sjoerd_> that;s not so bad either 22:36:27 <sbp> I'd say more "updated" than "fixed" :-) and thanks! 22:36:44 <sbp> do the results still validate? same amount of triples? 22:37:16 <Sjoerd_> exactly the same 22:37:50 <sbp> great 22:39:53 <Sjoerd_> I love it how you can handle special cases in xslt 22:40:39 <dajobe> bye 22:40:42 <dajobe> dajobe has left #echo 22:40:52 <sbp> c'ya dajobe: thanks 22:42:04 <Sjoerd_> <rubys> If we are at a stable point... perhaps it is time for wider feedback? 22:42:23 <sbp> I have an odd feeling that this has been the fun bit, adn now explaining it to hundreds of people is going to be a little... harder... 22:42:34 <bitsko> :D 22:43:41 <Sjoerd_> I like the ef format better than the 0.2 format, even besides the cool EF stuff 22:43:59 <sbp> yeah, me too 22:44:07 <Sjoerd_> maybe we shouldn't tell anybody that's it's about rdf 22:44:28 <sbp> I've tried to keep the mentions of RDF to a minimum on the wiki pages 22:44:52 <sbp> note how I've used "entity/resource" and "property/edge/arc" 22:45:09 <sbp> I'm not quite sure what to put there 22:45:32 <bitsko> maybe "transformable to RDF" in place of "RDF compatible"? 22:45:39 <sbp> and I'm worried about EF meets www-rdf-interest, too 22:45:46 <sbp> that's a good idea. changing 22:46:45 <sbp> whoops, I should update that status, too 22:47:32 <bitsko> I'm not sure the part about "expanding shortcuts" is necessary. it seems perfectly appropriate to model author as a property of the feed, and entry "gets" the author of the feed if it doesn't specify one itself. 22:48:20 <Sjoerd_> I like the point of view the tutorial takes 22:48:21 <sbp> okay. I'll factor it out 22:48:49 <Sjoerd_> EF solves typing issues that would otherwise require a schema 22:49:37 <sbp> note that I was using N-Triples before instead of OOP :-) 22:50:33 <Sjoerd_> you can probably switch from triples to oop with one regexp 22:50:42 <sbp> heh, yes 22:52:39 <sbp> changed a stray @href to @ref, and got rid of the <atom> elements in the tutorial 22:53:16 <Sjoerd_> it's a good thing atom:atom is gone, all the api xml docs are now EF too 22:53:32 <sbp> hmm 22:55:18 <sbp> this sort of stuff should use @ref, really:- 22:55:18 <sbp> <create-entry>http://example.org/reilly/</create-entry> 22:55:18 <sbp> <user-prefs>http://example.org/reilly/prefs</user-prefs> 22:55:24 <sbp> - http://bitworking.org/rfc/draft-gregorio-07.html 22:55:46 <Sjoerd_> yes 22:56:08 <Sjoerd_> oh, EF solves an xml:base problem too 22:56:33 <sbp> how so? 22:57:03 <Sjoerd_> otherwise you wouldn't know to which values xml:base would apply 22:57:20 <Sjoerd_> certainly a big problem for extensions 22:57:23 <bitsko> +1 on api using @ref 22:57:46 <sbp> hmm. that's a good point 22:58:07 <sbp> and I need to check xml:base support in the Python/SAX parser... 22:58:13 <sbp> bitsko: the *magical* @ref :-) 23:04:16 <bitsko> * bitsko notes Simon Willison's PHP comment on the API to atom-syntax, re. not supporting HTTP headers 23:05:03 <Sjoerd_> yeah, that seems odd 23:07:08 <bitsko> how can the #1 web app environment *not* support http headers? 23:07:30 <sbp> * sbp reads 23:08:22 <sbp> hmm. I can't believe that 23:08:30 <Sjoerd_> about the 0.2 RelaxNG schema, we really should jump in and make an atomEF RelalNG schema, but I also really should go to bed 23:09:02 <sbp> I was just about to look at that. http://tbray.org/ongoing/pie/0.2/ for the logs 23:09:08 <sbp> I might give that a go now 23:09:13 <Sjoerd_> * Sjoerd_ wants to switch to US time, but work can't let him 23:09:31 <sbp> I appreciate all the time you're putting into this 23:09:45 <sbp> you too, bitsko 23:12:28 <Sjoerd_> search & replace xsd:anyURI with Ref 23:12:53 <Sjoerd_> search & replace Id with Ref 23:13:12 <Sjoerd_> add Ref = attribute ref { xsd:anyURI } 23:13:25 <Sjoerd_> that's about it 23:14:19 <sbp> hmm 23:14:40 <sbp> I wonder if it's possible to make an RNG schema for the EF, sans Atom application? 23:14:59 <Sjoerd_> absolutely 23:16:04 <sbp> so then technically, it'd create a document class of which the AtomEF RNG schema would create a subClass 23:16:20 <bitsko> ie. a schema that can do generic extension model validation? schweet! 23:16:49 <Sjoerd_> I think you can do that 23:17:11 <Sjoerd_> I haven't tried subclassing anything with relaxng yet 23:17:30 <Sjoerd_> but it has some powerful features for that 23:18:16 <Sjoerd_> I think your grammar is already pretty close 23:18:33 <bitsko> who's our PHP expert? 23:18:46 <Sjoerd_> start = element atom:atom { property* } | property 23:19:01 <Sjoerd_> make that Property 23:19:16 <rubys> rubys has joined #echo 23:19:33 <sbp> * sbp needs to read about it carefully 23:19:39 <Sjoerd_> Property = SimpleProp | LiteralProp | ComplexLiteralProp 23:20:19 <bitsko> woot! if I translate $_SERVER correctly, it is listing the *common* CGI variables. so if it translates well across CGIs, there should be no problem getting HTTP_ATOM_AUTHENTICATION 23:21:16 <bitsko> http://www.phpfreaks.com/phpmanual/page/reserved.variables.html#reserved.variables.server 23:21:40 <bitsko> * bitsko apt-gets php 23:21:47 <Sjoerd_> SimpleProp = element * { Ref?, Property* } | element * { Ref } 23:22:02 <Sjoerd_> almost there 23:23:02 <Sjoerd_> LiteralProp = element * { text } | element * { Mode, XML } 23:24:12 <Sjoerd_> ComplexLiteralProp = element * { attribute *, XML } 23:24:45 <Sjoerd_> Ref = attribute ref { xsd:anyURI } 23:25:10 <bitsko> ruh roh. apt server gone missing :( 23:25:17 <Sjoerd_> Mode = attribute mode { text } 23:27:31 <sbp> { attribute *, XML }--won't that include namespaced attributes too? 23:28:21 <sbp> { attribute noNS:*, XML } perhaps 23:28:38 <sbp> where namespace noNS = "", as in Bray's thing 23:28:54 <Sjoerd_> why? what's wrong with namespaced attributes? 23:28:59 <bitsko> re. PHP, that page says that $_SERVER provides all the vars according to CGI 1.1 23:29:27 <Sjoerd_> thinking about that, there's a bug in my xsl 23:29:30 <sbp> they're not allowed, really, at the moment 23:29:47 <Sjoerd_> because... 23:29:55 <sbp> it's kinda a bug in mine, too; it's non-validating, that's all 23:30:08 <sbp> because: no reason, really. just simplicity 23:30:30 <Sjoerd_> works in the xsl now 23:30:40 <sbp> TODO: update the Python/SAX 23:30:50 <Sjoerd_> <xsl:template match="@*[namespace-uri()='']" mode="property"> 23:30:50 <Sjoerd_> <xsl:element name="{name(.)}" namespace="{namespace-uri(..)}"> 23:30:50 <Sjoerd_> <xsl:value-of select="."/> 23:30:50 <Sjoerd_> </xsl:element> 23:30:50 <Sjoerd_> </xsl:template> 23:30:54 <Sjoerd_> <xsl:template match="@*" mode="property"> 23:30:55 <Sjoerd_> <xsl:element name="{name(.)}" namespace="{namespace-uri(.)}"> 23:30:55 <Sjoerd_> <xsl:value-of select="."/> 23:30:56 <Sjoerd_> </xsl:element> 23:30:58 <Sjoerd_> </xsl:template> 23:31:02 <Sjoerd_> note the one dot difference 23:31:18 <sbp> yep. heh, good stuff 23:32:47 <Sjoerd_> that takes care of Sam's feature request #2 23:33:01 <sbp> he has two feature requests? 23:33:46 <Sjoerd_> 3, for rdf 23:34:12 <Sjoerd_> #1 was already done 23:34:20 <Sjoerd_> #3 isn't 23:37:05 <f8dy> f8dy has joined #echo 23:39:48 <imajes> heya mark 23:41:39 <bitsko> php is segfaulting :( 23:41:48 <imajes> in what way 23:42:14 <bitsko> from the command line, it works. via apache, it's segfaulting all the apache processes 23:42:28 <bitsko> apache isn't giving any other info that I can see 23:42:28 <imajes> hmm 23:43:18 <bitsko> php 4.2.2 23:44:29 <imajes> upgrade!! 23:46:06 <sbp> okay, Python/SAX updated 23:48:53 <Sjoerd_> about subclassing in RelaxNG: I think that after including above schema,every element definition should be appended with & Property 23:49:45 <Sjoerd_> Or, now that I think of it, maybe only the feed element 23:50:53 <burtonator> burtonator has joined #echo 23:51:03 <bitsko> quick note sent off re. PHP 23:52:28 <Sjoerd_> so to subclass EF, you'd only have to say: start &= external "ef.rnc" 23:52:41 <sbp> what're Sam's feature requests again? 23:52:47 <sbp> hmm. that's neat 23:53:19 <imajes> bitsko: to who, php-dev? 23:53:23 <Sjoerd_> 12http://www.intertwingly.net/blog/1566.html01 23:53:48 <bitsko> atom-syntax, in reply to Simon 23:54:02 <Sjoerd_> if start &= external "ef.rnc" works, then RelaxNG is really brilliant 23:54:07 <sbp> ah, I see 23:54:18 <sbp> agreed 23:54:47 <bitsko> RelaxNG brilliant +1 23:55:58 <Sjoerd_> I wonder if the result is then still convertable to XSD