00:02:54 protocol7 has joined #echo 00:11:08 rubys has joined #echo 00:52:10 jcgregorio has joined #echo 01:13:58 jcgregorio has joined #echo 01:27:05 jcgregorio has joined #echo 01:37:57 ta da: http://www.intertwingly.net/wiki/pie/ExtensibilityFramework 01:39:22 will that parse as RDF? 01:39:22 burtonator has joined #echo 01:40:37 sbp: can you define RDF compatible? 01:41:27 it won't parse as RDF, quite. RDF compatible in this case means again, it has to be transformed 01:41:33 but if you look at the transformation, it's generic 01:41:54 that is, the only element that it actually relies on being there from the atom: namespace is /atom:atom--the root element 01:42:29 therefore, people can define extensions and, as long as they follow a couple of rules, the extensions will be converted by the transformation into RDF 01:42:42 not only that, but other people can reuse this same transformation for their own format 01:43:01 so you might end up with lots of atoms--a bit of a grey area, but if people catch on, there are some extra steps one can take 01:43:21 it means that people wouldn't even have to support XSLT, necessarily 01:43:22 if there are rules, the validator can be made to check for them 01:43:28 yes, absolutely 01:44:05 my only real concern is that in the past 48 hours the argument has move from "give me triples or give me death" to "give me RDF/XML or give me death" 01:44:18 yes... 01:45:22 my concern has been that either a) people are going to be forced to support arbitrary transforms in RDF applications (won't happen) or b) the RDF/XML that people concede to for Atom will result in a horrid model, and RDF developers won't fix it at parse time 01:45:53 I feel that we're very strongly headed towards one of those situations; a compromise which is going to hurt everyone, rather than be a happy medium 01:46:29 s/ url=/ href=/ 01:46:49 you want me to change it? I can do. why href? 01:47:29 (note that uri was an arbitrary choice too; I'd just seen it being used from time to time when Atom had attributes) 01:47:41 http://simonstl.com/projects/foaf-xml/FOAF.xml 01:47:57 http://simonstl.com/projects/foaf-xml/ 01:48:04 okay 01:49:33 Here's a test: we have people strongly arguing that summaries and titles should allow HTML. While this is controversial, how would the syntax change if this were allowed? 01:50:10 okay, I've changed the transform example and the wiki 01:50:24 actually, I don't feel it's too controversial--I was going to propose it myself 01:50:47 sketch out how titles will look... in the normal case where there are no special characters. 01:50:50 it's good from an i18n standpoint because it allows Ruby (the markup for Kanji text runs) 01:50:53 okay 01:51:33 01:51:34 Atom 0.2<em>-ish</em> snapshot 01:51:34 [...] 01:51:34 01:51:58 why doesn't content look like that? 01:52:02 if HTML isn't used, the type attribute is not necessary, even if HTML is allowed 01:52:30 because content is converted to a propertyElt, with a Resource parseType on it. but look at --it's got a type="literal" on it 01:53:06 why can't content be handled the same way as title? Is title text/plain or text/html? 01:53:25 the general rule is: if it's got an @id, it's a node; if it's got an @type='literal' it's a property with literal content; otherwise it's handled as a propertyElt with rdf:parseType="resource" 01:53:36 the title's content is XML now 01:53:40 before it was just a string 01:54:07 doesn't actually contain the content of the entry. it's which does that 01:54:22 in fact, we could change it so that has the value, like Aaron's proposal 01:54:30 but this is what bitsko and I were talking about the other day 01:54:40 we decided that Aaron's model was going to be too restrictive 01:54:49 so we changed it. it can be changed back 01:54:55 I still don't see why content and title are different. 01:55:56 this:- 01:55:56 01:55:57 application/xhtml+xml 01:55:57 01:55:57
01:55:57 Let's take my favorite example: how would you express "Ben & Jerry's" as a title? As content. 01:55:58 01:56:00 01:56:06 becomes this RDF:- 01:56:07 01:56:08 application/xhtml+xml 01:56:08 01:56:10
01:56:12 01:56:14 01:56:28 as a title? Ben & Jerry's 01:56:50 now, how would you bold the 'e' in Ben? 01:56:50 same as in the current AtomXML 01:57:12 B<strong>e</strong>n & Jerry's 01:58:43 what I'm doing is defaulting to type="resource" 01:58:55 as you've obviously noticed :-) 01:59:16 but that still means that one has to use type="literal" in rare instances. it just so happened that AtomXML only uses it once so far 01:59:27 my problem is that <title> will be interpreted as HTML. 01:59:31 if you look at Aaron's atom.dtd, there's only one parseType="Literal" 02:00:09 I don't follow. in this model, that'd get converted to a text string in RDF, and everything'd be fine 02:00:33 the question is whether that text string is to be thought of as encoded HTML, or plain text 02:00:42 I see 02:01:03 Ben &amp; Jerry's would be the correct way to express this in HTML 02:01:21 this framework is agnostic to that. it only requires type="literal" to be used when there's actual XML content. but if you're asking from a general perspective... 02:01:29 People get this wrong all of the time. So much so, that what I was originally proposing is that every 02:01:31 I'd say get people to use unescaped HTML 02:01:49 string be treated as plain text UNLESS declared otherwise. 02:02:08 unescaped HTML isn't allways well formed 02:02:34 you'd not expect people to be able to at least make their titles and summaries well formed? 02:02:37 hmm 02:02:42 sadly, no 02:02:49 then you'd have to escape it permanently, you're right 02:02:59 which would be horrible 02:03:28 unless you started qualifying it with attributes 02:03:32 That's a problem with both RSS 1.0 and 2.0. 02:03:39 ... 02:03:39 yeah 02:03:49 I've followed the discussion 02:04:13 at the moment, what you are calling encoding is called mode. Tim Bray would say that encoding is the wrong term. 02:04:23 escaped is the correct term. 02:04:51 hmm. yeah, sorry. that is bad terminology given character encodings 02:05:04 Since you are designing a framework with a blank slate, I'd personally treat mode and type as part of the framework. 02:05:14 so modes. it seems to be generally sorted for 02:05:26 ah! well, that's a point 02:05:55 I did think at one point that the mere presence of a mode/type attribute could be used to signal an rdf:parseType="Literal" 02:06:05 which would mean that Atom would be free to use it for its own purpose 02:06:25 which would make it seem not only less obtrusive, but actually essential 02:07:03 from a reusability point of view, it'd be fine too. in fact, it might entice people to use it 02:07:12 You said you wanted HTML for Kanji. Suppose feed/author/name is Kanji. 02:07:27 okay 02:08:14 would mode/type also be applicable there? 02:08:16 (reference to Ruby: http://www.w3.org/TR/ruby/) 02:08:26 I'm familiar with Ruby. ;-) 02:08:42 ah, my apologies. good for the logs, though 02:08:49 Search for Ruby on google. The language is #1. I'm #2. ;-) 02:09:09 heh. I searched for ruby xhtml and you were #1, and ruby language was #2 02:10:19 in any case, again, the model as I've hacked it up now only specifically requires @mode/@type when there's XML content. if the Author's name required , then @mode/@type would be required, unless it were escaped, but then if it were escaped an @mode/@type might be useful anyway 02:11:01 when you say escaped, realize that you really mean double escaped. That's where most people get lost. 02:11:09 since you'd probably want to allow both, you'd best make it mandatory. and there's no problem there from the framework point of view 02:11:32 yep. I realise that. it's something that'd have to be documented with lots of in the Atom specification :-) 02:11:54 it is a bit counter-intuitive 02:11:56 people don't read specs. And this is hard for a validator to check for. 02:12:02 yes... 02:12:57 hopefully, if enough blog-software people implement it correctly in their templates, people will twig. if the view-source clan are to be believed 02:13:32 perhaps you could call the @mode/@type double-escaped 02:13:52 Ben &amp; Jerry's 02:24:27 My only bias is that literal and resource are indistiguishable for simple strings (i.e., ones without special characters). 02:25:03 jenglish has joined #echo 02:25:30 it's based on XML content. if test="*", then it's a resource 02:25:49 in fact, strictly, it should be if there are only XML element children and no text node children 02:26:37 double-escaped content meets that criteria 02:27:00 double escaped content won't have any XML in it, will it? 02:27:34 I'm not sure I understand the question. People today double escape XHTML into content:encoded. 02:27:55 okay. got that, I use it myself 02:29:12 So, again, I would argue that for simple characters, resource vs literal has no meaning. 02:29:45 I don't follow. can you give me some markup examples to follow, please? 02:30:10 Hello World Hello World 02:30:17 Both are treated exactly the same in Atom 0.2. 02:30:41 okay. both are treated exactly the same using the new framework, too 02:31:05 (in RDF terms) 02:31:40 Goodbye <strong>cruel</strong> world Goodbye cruel world 02:32:09 again, both treated the same way, as each other 02:32:22 and the same as the above, too. oh. I see 02:34:04 Ben & Jerry's == Ben &amp; Jerry&apos;s 02:34:57 so you're saying that @type would have to be preserved in the transformation, or moved off? 02:35:16 the last example forgot the mode. 02:35:37 yep. I understand 02:36:49 I'll presume that <mode>text/html</mode><value>Ben &amp; Jerry&apos;s</value> is not an option? or is it? 02:37:03 it'd mimic , then 02:37:24 has the problem that you can have a mode and a MIME type 02:37:46 What that would mean is that I would have to say Sam Ruby to preserve future extensibility. And pretty much do the same for every string values property. 02:39:22 value could map to somethingvalue 02:39:57 ok 02:39:59 which is actually pretty logical 02:41:08 2003-08-05T12:29:29Z => 2003-08-05T12:29:29Z 02:41:40 well, it's up to you: either only if there are attributes present, or not 02:41:54 (and whoops, ..., btw) 02:42:19 hmm, no 02:42:37 otherwise it'd make literal values impossible without type="literal" 02:42:42 I guess we are not in sync yet. What does Big News! map to? 02:43:04 Big News! I would like to map to Big News! in RDF 02:43:21 what does <attr>something</attr><rdf:value>Big News!</rdf:value> 02:43:51 * rubys goes back and inserts the missing close quote in the line above 02:43:58 heh, heh 02:44:27 RDF consumers won't have a problem with the morphing that you did above? 02:44:51 Will they get radically different triples? 02:46:16 yes. [ :title "Big News!" ] for the first one, and [ :title [ :attr "something"; rdf:value "Big News!" ] ] for the latter 02:46:50 hmm 02:46:55 surprises are never good. 02:47:01 no 02:47:08 mapping both to the latter approach would be better 02:47:15 but are they good in the Atom world, either? 02:47:52 if you suddenly change it so that an extra attribute changes the meaning sometimes of the element content, parsers will have to look out for that in advance 02:48:04 I don't think that they do. 02:48:52 Ben &amp; Jerry's will mean something different to Ben &amp; Jerry's, won't it? 02:48:59 I personally believe that resource = literal. The real difference is whether things are single escaped or double escaped. 02:50:33 both of those do mean something different. My thoughts there are that I see both in the wild today. So, instead of telling one set of people that they got it all wrong, it is much better to say that all they need to do is declare how they are doing things. 02:51:20 it's possible to make it so that blargh maps to <rdf:value>blargh</rdf:value> and require type="literal" for explicit literals... it's just a little less convenient. but if it's what's required for Atom, then it seems like it woud be a good idea to do that--a good precedent 02:51:53 okay. I was just wondering how Atom parsers would be expected to handle it if there were a transition 02:52:20 if they mean something different, and one day Atom switches from the former to the latter, are parsers going to break? if not, does it mean that they have to watch out for attributes? 02:52:59 I'm suggesting that a few attribute names be reserved. You did it with id and url/href. Type and mode could also be part of the framework. 02:53:50 * rubys lightbulb dimly flickers 02:53:53 yep, I understand that. that'd be a given, I think 02:54:21 heh. is that a half formed inspiration/realising/idea, or a notice that you're getting fatigued? 02:54:39 i'm starting to see what you are getting at <strong>foo</strong> 02:54:39 or that your power's going down... :-) 02:55:02 What you want is an unabiguious way to determine that strong is part of the value for title, but that title is a property of entry. 02:55:38 yes. at the moment, I do that by adding a type="literal" attribute on 02:55:56 <rubys> so, mode="xml" (in Atom 0.2 terms) is REQUIRED if there are ANY non-text nodes in the resulting DOM 02:56:05 <sbp> exactly 02:56:35 <rubys> if there are no non-text nodes, it can be omitted (in this case, literal==resource) 02:57:11 <sbp> yep 02:57:30 <sbp> (not sure what you mean by literal==resource in that case) 02:57:49 <sbp> but yes, if there are no elements, you can omit it. the test is on ./* 02:58:26 <PhilOR> PhilOR has joined #echo 02:58:59 <rubys> So, what should <title>foo and 2002 map to? 02:59:05 Say, can someone explain to me how http://intertwingly.net/stories/2003/08/10/maxAtom.rdf manages to be valid RDF? I'd've thought you need rdf:parseType="literal" on the xhtml:body element. 02:59:06 * rubys waves at Phil 02:59:39 they would map to foo and 2002. unless you wanted me to make them map to similar things but with 02:59:50 what would they map to in RDF 02:59:52 Joe: take a look at the atom.dtd in the same folder 02:59:57 jenglish: look at http://intertwingly.net/stories/2003/08/10/atom.dtd 03:00:13 that is RDF. they'd be literal values. :title "foo" and :modified "2002" 03:00:14 a validating parser will add in all the Fixed attributes 03:00:36 Ah, I see. Thanks. 03:01:17 if you like, foo and 2002. they're pretty much the same thing in RDF 03:01:20 sbp: I think it need to be :title [ rdf:value "foo" ]] 03:01:32 okay. in that case, that mapping could be made 03:01:46 for both title and modified? 03:01:49 yes 03:02:09 if you want to prevent one from being mapped that way, you can add type="literal" 03:02:34 I think it is necessary for content. Likely needed for title. Not required (nor harmful) for modified. 03:02:45 That's why I'm picking on these examples. 03:03:04 if foo has to map to :title [ rdf:value "foo" ], then the only way to make modified map to :modified "2002" is to use 2002. hmm 03:03:11 yep. it's good that you are! 03:03:36 I agree that it's necessary for content, though it can be modelled as an actual resource in that case 03:03:43 So, I'm suggesting that it also needs to be :modified [ rdf:value "2002" ] 03:04:09 yes, if the type="literal" attribute is too obtrusive 03:04:23 certainly would be for things like modified. 03:04:28 yeah 03:04:49 if modified had to be that way, it wouldn't be much of a problem 03:05:15 in fact, you can shoehorn datatypes in that way, perhaps. and it'd make the querying consistent 03:05:38 FYI: I will probably break for the night shortly.... 03:06:13 on a side note, I've been thinking about how to handle this with XML Schema datatypes, but there's no way to do it without making lots of implicit assumptions about bits of the instances... 03:06:22 yep, s'fine. thanks for all the input! 03:07:06 one thing I like about XML schema is that it is optional. The client can apply it if it wants to. And different clients can apply different schemas. 03:07:42 same with all XML schemata languages, I suppose 03:08:09 unless that's what you meant... sorry 03:08:32 it's a late-nighter for me too:- 03:08:35 .time +1 03:08:35 Sun, 17 Aug 2003 04:04:22 +1 03:10:18 I'll update the transform to map to rdf:value for cases where propElts don't have @type='literal' but may or may not have attributes useful to Atom 03:15:48 * bitsko arrives home 03:16:13 welcome back, bitsko 03:16:41 I'm just reading up on ExtensibilityFramework 03:17:01 yes. sorry--a lot of the discussion about it has been IRC-log only at the moment 03:17:05 and I'm still hacking on the XSLT 03:17:15 np 03:21:36 are there any open issues still? I can't readily tell from the irc log 03:24:54 hmm. the model of literals is the main issue 03:25:07 but it's been tentatively resolved 03:25:32 xml or string literals? 03:26:17 it's the question of what blargh and blargh etc. map to in the RDF model 03:27:11 we've decided upon :title [ rdf:value "blargh" ] for the former and :title [ :mode "double-encoded"; rdf:value "blargh" ] for the latter. to force :title "blargh", one would use blargh 03:29:44 note that there's a modeling hiccup in the current Atom form of itself. 03:30:50 oh? I take the current as being application/xhtml+xmlxml
:-) 03:34:49 the hiccup surrounds the default representation of the "entity", in the HTTP/MIME sense. the "characters" that make up the content. 03:36:36 okay. HTTP entities are series of octets. they can be represented just fine in XML, no? 03:37:23 yes, as long as one logically substitutes "XML characters" in place of "octets" for entities not in base64 03:39:18 the definition of "mode" is inverted on some content types, inadvertently 03:39:44 ah. I think I understand 03:41:11 the Atom mode "escaped" is equivalent to an RDF string literal. the Atom mode "xml" is equivalent to an rdf:parseType=Literal. (base64 is also a string literal) 03:43:38 * sbp is tiring, and has to be up early 03:44:33 k. I'll read up and see if I can pinpoint if there's any issue 03:44:48 many thanks 04:05:50 XIOR looks interesting 04:09:02 rubys has joined #echo 04:11:48 "several talks discussed generalizing XPath for directed graphs (which I freely admit would be a much better solution than the one I presented in RDF Twig)" -- ndw 04:12:53 .time 04:12:54 Sun, 17 Aug 2003 04:08:39 GMT 04:13:28 chatlog's clock is slightly fast 04:13:36 who is ndw? 04:15:34 Norm Walsh, quote from http://norman.walsh.name/2003/08/07/extreme 04:15:58 burtonator has joined #echo 04:16:41 ntp on my machine is hosed. seems firewall related. I can initialize time with ntp, but not maintain it. 04:16:43 .time 04:16:43 Sun, 17 Aug 2003 04:16:43 GMT 04:20:57 burtonator has joined #echo 04:47:01 emanu has joined #echo 05:02:12 emanu has left #echo 05:30:43 PhilOR has joined #echo 05:45:22 burtonator has joined #echo 07:16:49 db3d has joined #echo 07:17:20 atom discussions here? 07:18:29 no? 07:18:36 db3d has left #echo 07:26:47 db3d has joined #echo 07:31:28 /join 07:31:37 /who 07:31:50 /join #echo 07:31:59 /help 07:32:05 db3d has left #echo 07:40:12 db3d has joined #echo 08:29:34 d2m has joined #echo 10:50:17 Hat_ has joined #echo 11:20:13 Sjoerd has joined #echo 12:03:07 sbp, are you there? 12:47:14 dhaun has joined #echo 13:01:26 rubys has joined #echo 13:05:01 emanu has joined #echo 13:13:48 gluon has joined #echo 13:23:45 gluon-- has joined #echo 13:35:59 gluon-- has left #echo 13:58:41 jcgregorio has joined #echo 14:15:30 dwalker has joined #echo 14:45:08 rubys has joined #echo 14:58:30 KevinMarks has joined #echo 15:28:56 heh. one of the major features claimed of XML-RPC (automatic serialization) is also true of RDF. /me wonders why RDF advocates don't push that more. 15:31:04 that's weird reasoning 15:32:24 on my part? 15:32:33 prolly :D 15:34:40 what do you find interesting about XIOR 15:34:50 I do think it's odd that there's not an elevator pitch yet for "tell me what the immediate benefit of RDF is to *me*" (to quote jbeimler) 15:35:26 XIOR is one of the first formal docs I've read for stating a data model for XML as-is. 15:36:11 if you have to give a personal pitch, you'll have to know that person's goals 15:36:58 I've been tracking the "XML as data model" vs. "RDF as data model" discussion, and most of the "XML as data model" discussion has no basis in theory. XIOR would be one of those basing in the theory, thus making the discussion more interesting. 15:38:33 not necessarily a personal pitch, but more of a FAQ. addressing very commonly repeated concerns. 15:39:13 couldn't xior be done with regular Ids and xlink? 15:39:25 serialization and cross-reference resolution being one of the "immediate benefits", for example. 15:40:15 yes, I think that's what XIOR is doing almost exactly. XIOR is formalizing the profile for interoperable use. 15:42:06 during the recent scenario of experimenting with Atom syntax to discover if there is a "style guide" for creating XML structures that can be mapped to a data model (RDF) directly, XIOR appears to be along those lines as well. 15:43:32 I definately like the "@id as uri plus @href" style 15:45:36 with the tag: uri-space solving a lot of problems uris would bring with them without it 15:46:46 the tag: uri space is very good for examples, for the view-source purpose. many people don't grok the ID vs. location-ref duality of URIs 15:48:08 personally, I would *still* prefer that the ID URI be resolvable. in the API discussion, we haven't returned yet to discuss which element ( or or something new) is the actionable URI-location. 15:48:42 I'd say neither 15:48:54 has the more firm understanding as the "human viewable page in the context of the publisher's site" 15:49:16 neither == find something new? 15:50:04 let the server return where to go for a post with a certain id 15:51:15 some would say that's too round-trippy. 15:51:41 I don't see any other way 15:52:49 id cannot make concessions to being globally unique through time 15:53:12 link is exactly what you said 15:53:24 id -- good point. 15:53:56 and for a lot of systems the html page is impossible to be actionable 15:54:00 adding to the mix is one of the working suggestions. 15:54:29 yes, I think it's pretty well understood that can't be actionable. 15:55:03 by definition, that is. surely it can be actionable and equivalent to for some. 15:55:42 the html page can contain a to the endpoint as well 15:56:41 that's one of the most likely places too. I think it would be a good thing to promote metadata equivalency between what's coming in the html page and what's in the Atom feed 15:58:10 I had an interesting idea going the other direction as well: drop itself and just use in the API and feeds. 15:59:17 yeah, but by now I'm completely against reusing anything from another namespace 15:59:27 a way to use plain-text markup or editor-specific markup can still be provided, I'm talking about from consumer's perspective mostly 16:00:24 why's that? is there a specific case or two that's given you that position? 16:00:51 several reasons 16:01:08 reusing doesn't mean anything in xml 16:01:51 even if there seems to be a semantic match, there are always small differences that only show up in practice 16:02:18 and namespaces are ugly 16:04:33 the only place for mixing namespaces is including a complete subtree from another xml format 16:04:49 which reminds me, not exactly related: one technique for versioning namespaces is not to "replace" an old namespace with a new one when terms are added, just put the new terms in a new namespace and leave the old terms in the older namespace. 16:05:50 and even then only in places where the outer format has anticipated that, like soap:body, svg:foreignObject or xs:annotation 16:06:31 I've fallen on the other side of that position. I think namespaces are a given and should be used liberally. 16:06:58 then I'd use RDF if I were you 16:07:10 :) 16:08:15 my reasons for not using rdf are about the same as the reasons for not using namespaces 16:08:43 I came to that conclusion quite some time ago, and now expect all my xml tools to make using namespaces easy by supporting prefix syntax everywhere. I think programming languages should be updated to support them as field or key names. 16:10:44 so you don't like html dropping xlink (I do like it) 16:10:44 most of my projects in Python, for example, allow namespace use like item[DC.title] 16:11:45 what I *wish*, was Python to support item.dc:title 16:12:25 in programming, a namespace prefix doesn't have to be spearated with : 16:12:44 how so? 16:13:02 dc_title could also work, as long as you know in advance which vocabs you're going to use 16:13:46 that breaks across code ownership boundaries. specifically, one can't (shouldn't) code libraries that way. 16:14:35 more simply, it has scoping issues 16:17:18 I'm not really familiar in what ways the various languages solve including several libraries 16:20:40 <_dreamnofshannon> _dreamnofshannon has joined #echo 16:21:09 it not so much the language, the issue seems to be the same for many languages. If I created a "namespaceable" object in my module, and tell that object that the 'dc' prefix is Dublin Core, and I pass that object to another module which wants to tell the object that it uses the prefix 'dc' to refer to, say, Declarational Code, the object itself now has to know which caller (scope) is making the request, so it knows which namespace 'dc' refers to. 16:24:08 ah right, so namespaced objects should internally be compiled to qnamed objects, then any lib can use its own prefixes 16:25:40 well, sure. in that case, I'd suggest the language also use a new syntax token to make that conversion explicit, ':' would be a popular token :D 16:28:16 only : is such a nice operator that it would be a shame to see it wasted in identifiers 16:28:46 it could be made context sensitive. 16:29:35 namespaces will occur on almost any context 16:29:54 but we're getting really off-topic now... 16:31:31 the context would be a "name token". seperating the use of ':' in a name-token grammar from the use of ':' in other rules wouldn't be much different than for some other punctuation. 16:32:04 you haven't yet told me why you think namespaces should be used liberally 16:32:20 but yes, getting back on topic, you now know why I have no problems with namespaces everywhere. 16:32:55 right :) 16:34:09 the reason I think namespaces should be used liberally is because I've ran across namespace collision problems in data-driven, dynamic code. 16:35:33 whenever I have a "record" of some type that gets passed between several distributed blocks of code, certain blocks will want to add properties to the record. to do so, they need to be able to add those properties without fear of name collision. 16:36:26 before XML Namespaces, using module prefixes was the most common answer. 16:36:45 but all the "good" module prefixes are taken! 16:37:57 you should solve that by making property names scoped 16:39:33 I'm thinking how that would translate to xml 16:39:36 true. in exactly the same way we described using namespaces in a scoped manner. it took several years before I realized that XML Namespaces solved the same problem I was having, in a non-language-specific, portable way 16:39:50 danbri has joined #echo 16:40:13 any SOAP fans around? 16:40:35 now, for example, the records themselves can be passed between different languages and retain their property names. 16:40:53 danbri: I'm well read on SOAP, if not a fan of it 16:41:03 s/if/tho/ 16:42:31 I can see the advantages of adding an envelope aound a document, but that's about it 16:44:53 bitsko: what's the use of passing a record to another language, that doesn't know what to do with the namespaced properties? 16:45:29 how do you know which agents do or do not understand particular namespaced properties? 16:47:08 how do you know that other agents use the namespaced propertie in the same way as you do 16:47:28 the principle purpose of namespaced extensions in RSS (1 and 2) and PEA is for certain agents (producers, consumers, and middleware) to add their own bits that get propagated. 16:48:21 the globally unique names of the properties is somehow, somewhere linked with the information necessary for agent authors to write the right code 16:50:28 note, there's no magic in a globally unique name within that technique. as long as two agent agree on how a name is used, and no other agents use that name by accident, that would work just as well 16:50:52 yes, that's a good use of namespaces 16:51:19 but that's something different than replace title with dc:title 16:52:52 so, an element or attribute in a different namespace than the namespace of the host language, has a more specific use, not a more general use 16:52:59 how 'bout a different angle on that. If I'm building a record of my photos or documents, why *wouldn't* I want to use dc:title instead of making up my own title element? 16:54:13 if you're pretty sure, you're not abusing dc:title, then that's fine 16:55:09 yes. using the same names when they mean the same thing is a good thing, just as picking a new name when a new meaning is indicated is also a good thing 16:55:09 but note that in your case it's clear whose title it is: the record, in xml that's not clear at all 16:56:24 * danbri back, yes, SOAP Encoding has issues. I'm trying out an idea though... 16:56:39 max froumentin and i have been looking at using the SOAP Encoding rules as a new RDF syntax. 16:56:43 if you f.e. add dc:title to the of is it the title of the head, or of the html document? 16:56:55 and we're just now trying this out on Atom... 16:57:03 take the XIOR case, for example. if a record, indicated by its having an xior:xoid, has a dc:title, I can well assume that that dc:title is the title of the record. 16:58:09 even if you're 3 levels deeper? 16:58:29 no, as a direct child 17:00:19 I don't think XIOR can be taken as putting much more structure to records than that. 17:00:55 but it's already a lot 17:01:01 iow, XIOR seems good at locating "anchors" at root nodes of XML fragments. 17:01:25 XIOR is guha-et-al's thing? 17:01:26 I hadn't realised that yet 17:01:40 yes 17:02:54 Oh, you guys should note that despite the stylesheet etc on that page, it isn't a W3C Note of any kind yet. 17:03:11 I hope it will become one, and guess they're preparing a submission... 17:03:13 re. replacing title with dc:title or dc:title in the of html is a seperate issue. in those contexts, I'd be happy if somewhere it's just said "title can be treated as a dc:title" 17:04:00 I'd prefer if that somewhere was XR :) 17:04:36 :) 17:05:24 I'm not convinced yet that application-specific translations are viable long term (application in the XML sense, a vocabulary) 17:05:49 danbri: re. SOAP Encoding: don't go there. it's a tar pit. 17:06:28 note that XR can also extract RDF from textfiles once you have XSLT 2.0 17:08:52 bitsko, tell me about it! 17:08:58 yes, for working with legacy formats (XML or no), application-specific transforms will be great. I'm meaning more about new formats, *especially* those designed with extensibility up front, like RSS2 and Atom 17:09:02 i spent a while trying to get them to drop it from the spec. 17:09:10 but bear with me on this... 17:09:28 the tarpit is the use soapenc is being put to, as much as soapenc itself. 17:09:51 * danbri no fan of rpc in the web, but as a syntax for graphs in xml, soapenc has advantages over rdf 17:10:45 one can find many examples of graph syntaxes much nicer than soapenc... 17:11:56 in XML? that use namespaces? that are in W3C RECs? 17:12:03 Or do you mean N3? :) 17:13:03 Sjoerd: to be very specific, I think the idea of XR or XSLT as a normative technique to "get" RDF interoperability is not practical in the face of extensibility. 17:14:00 the idea is that each namespace defines an XR document, and they would then mix automatically 17:14:17 danbri: are you considering a profile of soapenc or the whole enchilada? 17:15:31 I hadn't started on doing any work on that, because initially XR wasn't picked up at all 17:17:05 Sjoerd: how does XR handle the scenario where an extension foo:bar is used in an atom:entry container and an rss:item container? and maybe in two levels deep in one while only one level deep in the other? 17:17:57 that would depend on how the atom xr and rss xr would handle unknown elements 17:19:22 there's a logical merging of the XR transforms? 17:19:41 between host format XR and extension module XR? 17:20:02 the way xslts merge 17:20:49 bitsko, most likely a profile. Perhaps two profiles, (a) a general convention for using soapenc as an rdf syntax. (b) a tighter profile for use in Atom feeds. 17:22:04 danbri: just for reference, SOAP doesn't appear to have much better reputation than RDF in the Atom discussion 17:24:49 Heheheh. Good. 17:25:18 All the more controversy I'll get for proposing we use SOAP *and* RDF at same time, then. ;) 17:26:27 Sjoerd: I'm an xslt novice. I understand that XR is used to produce XSLT, correct? what would the xslt for an extension look like, that it could be used "within" two seperate xslt stylesheets in the right position to select the right properties? 17:27:26 not at the right position, you can add it to the root 17:28:03 an XR defines templates for each element that can be used as a root in that namespace 17:28:44 an atom XR document would say somewhere: handle other elements here 17:29:23 then the extension would automatically kick in 17:31:10 without the extension having an XR? 17:31:25 no, not that 17:31:57 ok, so it is two XRs, one for the root and one for each extension, correct? 17:32:07 although I could make something that assumes the extension is valid rdf 17:32:11 right 17:33:05 I'm thinking the other direction, where the extension is deeper and is not RDF 17:33:14 , for example 17:34:11 currently the atom XR must anticipate all places that allow extensions, and say how they relate to what 17:35:54 in ["Syntax"], I referred to "those" places as "entities", which does have a good correspondence to RDF resources. as in the DTD experiment where rdf:parseType="Resource" was used. 17:36:52 iow, all entities are "the records" and those records allow any direct children as extensions. 17:37:55 yes, I could built something like that into XR, have to think about it 17:38:27 Sjoerd> currently the atom XR must anticipate all places that allow extensions, and say how they relate to what 17:38:36 yes, that's exactly the problem i worry about re extensibility 17:39:03 * danbri looking instead at mapping between data models 17:39:38 one of the differences that might occur between two XML styles, though, are repetition. one style might allow repeated elements where the other might have a wrapper element. vs. 17:39:53 that's a bit what XR does: map the xpath model to the rdf model 17:40:08 yeah... it's a jungle... you can't sanely leave it to extension vocab authors to make up whatever rules they like... 17:40:21 rubys has joined #echo 17:40:34 ya, I think that's the catch. 17:40:40 well, if each extension is a self contained island you could... but if they draw on mix of namespaecs you're screwed 17:40:51 eg. a jobs namespace that used foaf or vcard for contact info 17:41:08 the set of namespaces that my feed uses is determined by my template. 17:41:20 Hi Sam! 17:41:38 So, if there was a means for a person to generate a transformation that matches a given template, then we have a workable solution. 17:41:50 Hi Dan! 17:42:01 And, yes, proposing both RDF and SOAP seems to be the way to go. ;-) 17:42:05 yes, you'd need a transform per source... 17:42:14 were you reading the logs, or psychic? :) 17:42:19 logs 17:42:29 eek, transform per weblog?!?!! 17:42:36 transform per template 17:42:39 I though that was what you were saying... 17:42:45 Lots of people use a standard template. 17:42:47 ah, template may be common across several weblogs i guess 17:42:56 yep, i guess i was being overly melodramatic 17:43:06 With how rich Atom seems to be, a lot of people will probably not need much in the way of extensions. 17:43:32 I don't even see the catch Dan was talking about 17:43:38 yes, but most of the interesting extensions will happen outside of the mainstream blog tools... 17:43:48 I also like the direction that sbp was heading yesterday, but I respect Sjoerd's observation about inheritance of author. 17:44:00 big question! If it is mostly just for weblogs, I'd agree. if it is for all the uses of the Web (movies, jobs, maps, etc...) you'll want all sorts of extensions. 17:44:12 an extension can add all the properties it wants 17:44:19 and those extensions to be used elsewhere. 17:44:21 I got the impression initially that Echo was being driven by weblog requirements. But I got that from reading weblogs ;) 17:44:52 * rubys mutters to himself: RDF+SOAP-RDF/XML-SOAP/encoding 17:45:14 sjoerd, catch is that extension use cases and extension vocabs aren't 1:1 17:45:39 an extension for jobs might use a mapping/geo/address namespace; an extension for photos might use a big-list-of-nouns (eg. Wordnet) ns, etc. 17:46:06 and isn't clear who gets to make up the rules; the person who invents the extension practice, or the owner of the nampesace(s) it uses. 17:46:20 * danbri interested in sam's mutterings... 17:46:45 Got time to take a look at my afternoon's experimenting? (w/ MaxF): http://esw.w3.org/topic/SpotOfDrama 17:47:00 what we need is the equivalent of a FOAF-a-matic for generating transform unique to a feed 17:47:15 some sort of a 'wizard' thingy...? 17:49:24 danbri: what value add does soap encoding add to your experiment? 17:49:24 Sjoerd and I were discussing XR in that direction 17:49:53 bitsko: +1. And look at the RDDL experiment that SBP did. 17:50:11 danbri summarized the real issue, and isn't clear who gets to make up the rules; the person who invents the extension practice, or the owner of the nampesace(s) it uses. 17:50:30 neither 17:50:45 both get to propose. The creator of the feed gets to make the ultimate decision. 17:50:46 value add: depends on context 17:51:09 In a SOAP 'vs' RDF (or SW vs WS) context, it provides a formalisation of a common ground 17:51:42 In an Echo context, it provides a prettier-than-RDF/XML encoding, while hooking up to something that provides a model to underpin namespace extensions etc 17:51:49 Background: I've done soap for years. One of the authors of Apache SOAP and Apache AXIS. Chaired SOAPBuilder's interop events. 17:52:19 * sbp reads through the huge backlog 17:52:23 more generically, the creator of the containing xml instance gets to make the ultimate decision on how extensions are created. 17:52:28 ...and allows us to write *one* convertor that turns all this stuff into RDF, rather than having to write lots of bits of convertors and figure out (per SBP, Sjoerd et al's efforts) how those compose together. 17:52:30 soap envelope and header are goodness. Encoding is for when you aren't exchanging documents but are doing RPC. 17:52:51 Sam, yup, thats why I wanted to talk to you about this! 17:53:18 "Encoding is just for RPC" is something I'm not persuaded of. The SOAP specs have always been a bit bashful about this. 17:53:32 my recommendation would be to take your example and strike env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" 17:53:44 the SOAP specs simply state that everything is possible. 17:53:48 SOAP folks generally are pretty downbeat on the encoding rules, since they come with attached stigma of RPC... 17:53:57 'everything is possible'? 17:54:04 WS-I just came out with a set of recommendations. Short summary: avoid encoding. 17:54:13 they do specify a mapping of a node-edge-node model into XML Infosets 17:54:36 * bitsko misplaces the RDDL experiment SBP did 17:54:46 Yeah, I'm pretty narked about that. I made a stink trying to get SOAP Enc dropped from the W3C spec, and (nameless parties) said "no, lots of people want it!" 17:54:52 http://lists.w3.org/Archives/Public/www-archive/2003Aug/0011.html 17:55:09 and finally W3C makes a REC of 1.2 with Enc in it, just as not-entirely-different parties go round saying "Well actually encoding SUCKS". 17:55:30 * sbp gets to the bottom; hi guys 17:55:56 There are lots and lots of reasons not to do Encoding and RPC. And ways it can go wrong. But I feel given that W3C spent several years blessing SOAP, we (well 'we' as RDF folks) owe it to them to take a good look at the graph encoding syntax they propose. 17:56:33 * bitsko doesn't agree, but he's already said that! 17:57:20 I helped get something into the SOAP/XMLP WG charter to that effect... But it got blown off, since SOAP folks didn't want to get slowed down by risk of being talked into working on a 2nd RDF syntax... http://www.w3.org/2002/10/XML-Protocol-Charter 17:57:38 (see section 1.4 there for history / context) 17:57:40 essentially, the graph encoding that soap proposed is id/href. Allowing every element to either be inline or accessed via href created a lot of interop problems. 17:58:04 yup... 17:58:36 Apache impls do almost everything via href. 17:58:36 i never found a proper test suite for soapenc, except some stuff from the axis cvs 17:58:37 what kind of problems? 17:59:05 RDF's syntactic variations also created probs until we invented the n-triples syntax for parser testing 17:59:34 I looked at the way you did it in Axis; it was similar but used Java objects where RDF folks would use N-triples. 17:59:34 Sjoerd: what people would find is that they would quickly implement the spec, make choices about how they would use id and href, test against themselves and a few friends, and declare themselves done. 18:00:28 what we would often find is that the language influenced decisions like these. 18:00:49 is string a primitive or an object? Most people don't do primitives via hrefs. 18:01:03 more interestingly, can primitives be null? 18:01:05 ah, they couldn't even imagine people would do that 18:01:45 if I have an array of long strings, with all elements the same, I could express that very compactly with hrefs. 18:02:19 this is so reminiscent of RDF a few years ago... lots of corner cases and partial interop 18:02:22 now imagine how your xslt transforms would look like if could be done as a href. 18:02:58 doc literal avoids this - the body is defined by a schema. 18:04:10 ...but you get back into the space RSS currently plays in, where we're not really very good at mixing indpendently created schemas together without pre-coordination. 18:04:13 while simultaneously reverting all applications to manipulating the XML Infoset directly... 18:04:30 Not that SOAPEnc folk seem to notice that SOAPEnc could be used for anything other than RPC :/ 18:05:31 xml has ID and IDREFS, why did that never catch on? must be something wrong with it. (I don't even know how it works) 18:05:45 I haven't checked recently, but the .Net implementation of SOAP only supported EITHER doc/lit or rpc/enc. No other combinations. 18:06:33 sjoerd, It's very reminscent of the RDF situation there too. People say "urk, there are so many ways I could write the same thing, how can i write a sane xslt for *that*..." 18:07:06 rubys, I guess I'm just ripping off a chunk of the soap spec and acting as if they'd shipped it as a normal document format like mathml, html, svg, etc. 18:07:11 (ie ignoring the protocol use) 18:07:14 simply by making sure xpath resolves the refs 18:08:26 danbri: I guess I'm not sure I understand the problem you are trying to solve. Put RDF/XML in the body. Put transaction semantics in the header. Add an envelope. Done. What am I missing? 18:09:42 * danbri no fan of rpc in the web, but as a syntax for graphs in xml, soapenc has advantages over rdf 18:10:07 yeah, RDF/XML in the body would work as well as SOAP Enc for many of the apps I care about (though SOAP toolkits would be unlikely to provide aynthing to help). 18:10:24 Problem currently is that of folk going "RDF: datamodel nice, syntax: yuck..." 18:10:45 hence trying to find a cross-vocabulary alternate XML representation for *all* of RDF. Rather than doing it piecemeal. 18:11:26 ie. instead of doing RSS/AtomML and FOAF and xyz as non-RDF XML then trying to deal with mapping rules for each separately, come up with a whole new syntax all at once. 18:11:30 in that regard, one must realize that the people *most* knowledgable of soapenc are the ones saying "yuck", not the onlookers. 18:11:52 The strawman being that we can pinch the unfashionable SOAP Encoding syntax and rip it off, make it into a new RDF syntax proposal. 18:12:14 Notice that the SOAP Enc'd Atom eg in my wiki page is pretty close to Aaron's prettified RDF example. 18:12:31 This is because both use an unstriped encoding style, whereas typical RDF is striped and hence verbose. 18:12:49 (does the "striped" terminology make sense to you?) 18:12:57 yes 18:13:04 * danbri was digging out http://www.w3.org/2001/10/stripes/ just in case 18:13:38 I'm very interested in where you are heading. I'm not sure that SOAP encoding is the answer, but I'm willing to spend the time telling the pro's and con's and real life experiences I have had with it. 18:14:18 I'd be very interested to hear. I started looking into SOAP Enc as an RDF syntax end of 2001, and also at same time proposing mapping to RDF triples as basis for doing interop testing for SOAP Encoding implementations. 18:14:29 I wanted W3C to have a test suite for that bit of the spec, something machine-readable. 18:14:35 I think we need to try out every possible solution, that'll hopefully lead to seeing the big picture 18:14:38 Nobody seemed that interesting though... 18:15:04 quick background on soap encoding: 18:15:10 rubys, are you still involved w/ axis? 18:15:29 it was a snapshot of XML schema as it was before it was standardized + arrays + id/href. 18:16:02 s/was/used/ ? 18:16:18 danbri: I am still a Axis committer, on the WS PMC, and the Apache board of directors, but haven't been active lately. 18:16:40 no SOAP Encoding predated XML schema 18:16:57 so SOAP encoding is a snapshot of XML schema as it was 18:17:15 there were a mix of precursors as I understood it... some of it via Andrew Layman's post-RDF work, after Microsoft dropped out of the RDF universe in 1998. 18:17:21 doc lit uses xml schema, but leaves undefined arrays and id/href. Arrays are obvious. 18:17:44 * danbri nods re predated, I meant it drew on what was then expected of XML Schema 18:18:25 http://www.w3.org/TandS/QL/QL98/pp/microsoft-serializing.html was related... 18:19:10 * bitsko associated soapenc with a higher order data model but never associated XML Schema with one. goes off to cognitate on that one. 18:19:40 * danbri talked to glen daniels a few times re Axis' soapenc and serializer/deserializer machinery, was interested to know how it handled incoming unknown properties 18:19:58 he said something like 'we drop them in a Hashtable for leftover stuff'... Did i remember right? 18:20:34 bitsko, the higher order bit was made more explicit in later specs. And yes, XML Schema didn't really have one (imho) 18:20:37 yes. A hashtable of glorified DOM elements 18:21:18 so you can drop arbitrary un-intelligible branches of xml subtree in there, not just flat attribute/value pairs...? 18:21:33 yes 18:21:46 Is it fair to say that soapenc implementations are generally not too happy with seeing extension namespaces everwhere...? 18:22:15 pretty much. 18:22:24 did i interrupt yr soapenc backgrounder...? 18:22:27 * danbri shuts up and listens 18:22:42 no, i was pretty much done 18:23:13 andrew's doc seems to presume that all targets of ids are resolvable within the document itself. 18:23:36 dajobe has joined #echo 18:23:50 yes, it was very closed world. 18:24:08 danbri: XML Schema didn't or still doesn't? 18:25:11 neither 18:26:49 maybe I should be crystal clear so both danbri and rubys can concur: this question relates to so SOAP encoding is a snapshot of XML schema as it was, doc lit uses xml schema, but leaves undefined arrays and id/href. 18:27:02 Hat_ has joined #echo 18:27:29 there are IDREF and IDREFS types, but I don't see any word on what that means 18:27:44 my understanding (thru implementation) of soapenc was that at all times I knew when I was gathering properties of a node and when a new node started. my understanding of XML Schema doesn't include that. 18:28:09 on my understanding, W3C XML Schema has no abstraction analagous to the graph structures underpinning both SOAP Enc and RDF. It's all about the Infoset. 18:28:25 bitsko: concur. That doesn't mean that applications can't come up with a means of handling arrays and id/href. 18:28:48 so would it be accurate to say that xml schema "leaves undefined arrays, id/href, and nodes" 18:29:03 it's the "nodes" part I'm focusing on 18:30:31 rubys, am i right in saying that soapenc guarntees when XML element ordering is signifcant vs not (and generally it is not). 18:30:34 ? 18:32:40 schemas can declare order significant. soapenc guarantees the first level of xml elements to be ordered. 18:33:02 * rubys answered the phone: hence the delay 18:33:39 * danbri trying to figure out how soapenc prefers URIs to look 18:33:42 something like: 18:33:42 18:33:42 Mark Pilgrim 18:33:42 http://diveintomark.org/ 18:33:42 18:34:00 spec somewhat devoid of examples 18:34:35 that's right 18:35:47 dda has joined #echo 18:37:32 sam, what's the appropriate binding for xsd? 18:37:40 * danbri can't find it in spec... 18:39:02 http://www.w3.org/2001/XMLSchema 18:39:22 ta 18:39:23 (you can also use 1999 or 2000/10 in place of 2001) 18:39:31 joy 18:40:45 mostly the same, some annoying differences (timeInstant became dateTime) 18:42:23 rubys: non sequiturly, instead of rdf:value structures for literal content, I've tried datatypes, and I'm very happy with the results. files are in the same place--http://infomesh.net/2003/atomef/ (the 01- prefixed ones are the *old* files) 18:45:15 I believe that it addresses all of the concerns from last night 18:45:21 why is title double encoded? 18:45:51 just to show that it can be done? 18:46:02 yep 18:46:09 issued is mode literal or type literal? 18:47:08 shouldn't type be an attribute on content? 18:47:09 whoops; that was an experiment. I was just testing for the case where you have literal content with no XML children but you want it to be XML in the resulting datamodel 18:47:18 Why do we need a value within content? 18:47:25 I was confused :) 18:47:35 (sorry. I should change that) 18:47:55 value: because that's the way we seem to have had it for a while. it's how Aaron structured it 18:48:40 you could have it so it's
18:48:58 whichever, really 18:49:37 in een landschap ja 18:49:43 that's the nice thing about starting with a blank slate. you don't have to make nearly as many concessions, as long as what you result with is sane. and I'm operating under the principle that the model that works best for Atom will be the most reusable 18:49:55 Atom 0.1 and Atom 0.2 don't have it. If we are to allow html in titles, I would rather that titles and content be consistent. 18:49:56 * Sjoerd was typing in the wrong window 18:49:57 Sjored: pardon? :-) 18:50:02 s/re/er/ 18:50:12 rubys: sure 18:50:29 * sbp goes and hacks about with the XSLT and examples again 18:53:17 sam, are you sure it's xsd:type rather than xsi:type? 18:53:37 example: xsi:type="xsd:string" 18:53:41 * danbri adds work-in-progress example to end of http://esw.w3.org/topic/SpotOfDrama 18:54:25 again about: and isn't clear who gets to make up the rules; the person who invents the extension practice, or the owner of the nampesace(s) it uses. 18:54:35 ah! sorry was confused. which namespace is best for each? (v1.2) 18:54:40 * danbri is using xmlns:xsd="http://www.w3.org/2001/XMLSchema" 18:54:43 yup 18:55:06 why is it that (without an @id) is converted to parseType=Resource and (with an @id) is converted to an rdf:Description? 18:55:12 it seems that it's clear who writes the rules on dc:title 18:57:02 Sjoerd: no, dc:title only means "the content of this element is a title". it's up to the containing instance to relate that title to its parent elements. for example, when I said in XIOR that'd I'd expect a child element of dc:title to be the title of the xior:xoid element, it's because of the context of the XIOR usage, not the dc:title 18:57:13 public static final String NS_URI_2001_SCHEMA_XSI = 18:57:13 "http://www.w3.org/2001/XMLSchema-instance"; 18:57:13 public static final String NS_URI_2001_SCHEMA_XSD = 18:57:13 "http://www.w3.org/2001/XMLSchema"; 18:57:37 (cut and pasted from Apache Axis) 18:57:39 bitsko: so the rules are clear 18:57:42 ok cool, that's what I just committed. 19:00:09 in RDF terms: the host language defines the subject, the namespace authority defined the property and object (this is when the extension is a property) 19:00:46 burtonator has joined #echo 19:01:36 http://www.w3.org/2003/08/SOAPRDF/soapAtom-2.xml has foaf example in it now 19:03:05 trying...: 19:03:05 19:03:06 Mark Pilgrim 19:03:06 http://diveintomark.org/ 19:03:06 19:03:45 (a bit contentious given that there's no xml schema at the foaf namespace, but... whatever...) 19:04:01 why doesn't name have xsi:type="xsd:string"? 19:04:14 we could create a schema for the foaf namespace 19:04:38 I would fwiw be very happy to endorse something like this as an OK use of FOAF. Am waryer of saying it is ok to have it freeform mixed with arbitrary other tags. 19:05:05 yup, except it would have to be a super-liberal schema, to allow for rdf's freakish flexibility and XML Schema's not-being-relaxng... 19:05:32 name isn't xsi:type'd cos that seemed painfully verbose and somewhat pointless 19:06:01 perhaps foaf 0.2 could be a bit less freakishly flexible ;-) 19:06:13 can you explain the difference from a soap perspective, between foo and foo 19:06:34 If people weren't so freakishly interesting, it might be possible for a single schema to do the job of adequately describing them :) 19:06:47 in one case the data type is declared explicitly, in the other case, it is negotiated out of band. 19:06:49 until that day, I'll stick w/ extensibility over predictability... 19:06:55 Sjoerd: a working set of data to use as test cases might be to treat every complex element of Atom "as an extension" and see how it works. , , multiple s in a , etc. 19:07:02 ok, so it doesn't rule out that value being a string, good. 19:07:06 In no case is xsd:type required. 19:07:17 * danbri was only using it where it added useful info. 19:07:39 http://diveintomark.org/ also works 19:08:15 you are free to provide a 'hint' that this is an URI, but I am welcome to interpret it as a string anyway. And vice, versa. 19:08:19 yup... but it doesn't work for apps that care to be able to detect URIs wherever they're used without scooting around the web inspecting schemata 19:08:38 If I write type=anyURI, thats an assertion that it is a real URI, right? 19:08:48 yes 19:09:05 ...which the RDF conversion tool can use to map it into instead of treating the URI as a string. 19:09:10 Apache will respect that. .Net will ignore it. 19:09:20 ...which means that graph node gets auto-merged with other mentions of the same thing 19:09:43 which is a very RDFish concern, perhaps... but a healthy one: we want to aggregate data, after all... 19:09:53 Apache/.Net, interesting... 19:10:08 just remember that SOAP implementations aren't as freakishly flexible as RDF. 19:10:17 they will presume predictability 19:10:41 yup... 19:10:43 sbp? 19:11:01 Languages like TCL will map everything to a string no matter what you declare... 19:11:24 * bitsko considers that a good thing, too! 19:11:43 That's cool. I've no issue w/ the mapping to language stuff... I just want to know a URI when I see one, rather than have to go searching and querying for each new element/property. 19:11:55 RDF's syntax overhead for flagging a URI is seen by some as too costly. 19:12:15 Putting type=anyURI attribute on an element (to my eyes) looks more likely to be accepted by 'vanilla XML'ists 19:12:23 (even if they're SOAP skeptics w.r.t. big picture) 19:12:58 IIRC, that really isn't a SOAP construct, it is an XML schema construct. Just made popular by SOAP encoding. 19:13:08 If we could find a profile of this which (a) parsed into RDF generically (b) could get some use out of say Axis' deserializer (c) imposed a cross-vocab discipline on namespaces, I'd be happy. 19:13:26 http://www.w3.org/TR/xmlschema-1/#xsi_type 19:13:57 I can code/test (b) 19:14:59 re (b), that'd be great... 19:15:09 Is http://www.w3.org/2003/08/SOAPRDF/soapAtom-2.xml enough for you to be getting along with on that front? 19:15:21 it doesn't auto-convert to RDF properly yet, MaxF is still working on that bit of th xslt 19:15:29 http://www.w3.org/TR/xmlschema-2/ is fairly uncontroversial. http://www.w3.org/TR/xmlschema-1 is less so. 19:15:50 is there a big difference between adding explicit types with soap encoding, or just create an xml schema? 19:16:11 bitsko: you called? sorry. examples updated to use the new syntax 19:16:30 why is it that (without an @id) is converted to parseType=Resource and (with an @id) is converted to an rdf:Description? 19:16:59 basically, @id says 'this is still going to be a parseType="Resource" affair, but I want that resource to have the following @id as an @rdf:about, please' 19:17:18 declaring author a foaf person is a bit weird. The first child is an atom:name. 19:17:46 note that entry isn't converted to an rdf:Description. entry is converted to an entry; the rdf:Description is placed as a child so that a) rdf:parseType="Resource" isn't needed b) we have a place to put our @rdf:about 19:17:51 if this really were soap encoded, you would want the feed to be atom:feed and for the children not to be in the atom namespace. 19:17:58 I would still recommend doc lit. 19:18:13 rdf:about can be on the same element using an rdf:parseType="Resource", no? 19:18:15 it's exactly the same as if the @id weren't there, except it provides the object resource a URI 19:18:30 (that's my real question) 19:18:41 logecho, bookmark? 19:18:41 See http://bitsko.slc.ut.us/chatlogs/echo/2003-08-17#T19-18-41 19:19:09 ah, I see. nope, I don't think so 19:19:11 danbri: note that I don't have MultiViews workign yet, you need to add a .html to that 19:21:19 bitsko, i believe so, yup. 19:21:47 sbp: content should have something more than a simple div. 19:21:48 re rdf:about and parseType=Resource? 19:22:20 rubys: why? 19:22:48 what you have is legal, but is kinda.. vacuous 19:22:51 19:22:51 Mark Pilgrim 19:22:51 http://diveintomark.org/ 19:22:51 19:23:01 declaring author a foaf person is a bit weird. The first child is an atom:name. 19:23:05 ...that's interesting. 19:23:14 The reading I had of this, in terms of graphs and nodes etc... 19:23:52 is that the thing that is the value of 'author', ie. the node that author points in to, carries that type. And that node has an outgoing edge labeled 'name' pointing to a literal/string node 'mark pilgrim'. 19:24:13 I'm looking at it from an XML schema perspective. 19:24:25 I would have to declare a foaf:Person to make this work with Axis. 19:24:39 And in that definition, I would have an atom:name and a foaf:weblog. 19:25:14 * rubys mutters that Atom should just 'steal' all of the good FOAF properties... 19:25:29 we'll add 'em faster than you can nick 'em ;) 19:25:45 but I totally sympathise if you feel need to have the basics inline within Atom. 19:26:02 We should at least declare equivalencies (in RDF via subproperty etc). 19:26:20 rubys: on "content should have something more than a simple div"--okay, I'll add something 19:26:21 * rubys was just kidding, but hey! 19:27:15 * danbri had wondered about including some rss/cdf/mcf-ish channel markup in foaf, but wouldn't want to go there! 19:27:40 Can you elaborate on what Axis would need? 19:27:49 Is it not enough for Axis to know something is soapenc'd? 19:28:07 hey, since we can't come up with a name, perhaps including some rss/cdf/mcf-ish channel markup in foaf would solve two problems! 19:28:07 You need a real live XSD that says what elements go where... 19:28:35 I can write the XSD. But what you have now is a mix of encoded and literal. 19:28:37 I would love Atom/etc to be called MCF, the whole field got started there... 19:28:59 what makes it 'literal', i was trying to stick to what I can make out of Encoded :( 19:29:41 ? 19:30:32 if you want it to be encoded, change feed to be atom:feed, xmlns= to be xmlns:feed= 19:30:51 the child elements are not supposed to be in the atom namespace 19:31:08 child of...? 19:31:18 feed 19:31:39 in encoding, the immediate child of body is in a namespace. It's immediate children are not. 19:32:01 euw, i hadn't noticed that. 19:32:32 if you simply want literal, drop the encodingStyle 19:32:58 rubys: example augmented, validated, uploaded 19:33:02 nope, am trying to use SOAP Encoding Data Model, since it has same structure (minus some corner cases) as RDF. 19:33:10 so i'll stick w/ trying to use enc... 19:33:19 atom:xmlns="http://purl.org/atom/ns#" 19:33:25 ...and then etc inside 19:33:32 <danbri> and <foaf:weblog for the foaf bit. 19:33:34 <danbri> Is that OK? 19:33:36 <rubys> drop xmlns= 19:33:46 <rubys> the children are NOT supposed to be in the atom namespace 19:33:53 <danbri> which ns are they in? 19:33:57 <rubys> "" 19:34:24 <rubys> sbp: great! 19:34:28 <danbri> * danbri thought he'd asked about this in SOAP Last Call and got reassured it wasn't odd... but this seems odd... 19:35:01 <rubys> it certainly seems odd to me. 19:35:03 <danbri> from an XSLT etc perspective, it seems better to have the <title> etc in Atom's ns 19:35:25 <danbri> is there no way we can hack this? I mean, if the foaf: bit is OK, why not the rest? 19:35:33 <danbri> because I'm trying to use default ns? is that the problem? 19:36:41 <rubys> I don't believe it can be hacked, but will check. Yes, the default ns is the problem. Prefixes are irrelevant... they are just a means to an end. What really matters is what any given element resolves to. 19:37:15 <rubys> I'll be back in a bit. 19:37:17 <danbri> if we made 'feed' in a non-atom ns, could we use the atom url for the rest of the markup? 19:37:19 <danbri> okay, cu 19:37:36 <danbri> * danbri assumes that being able to use default ns is a requirement for Atom (simplicty etc) 19:40:26 <emanu> emanu has joined #echo 19:45:48 <sbp> * sbp moves xml:lang from content to div 19:47:18 <Sjoerd> sbp: I really like where this is going 19:48:16 <sbp> thank you. me too, though I wasn't sure that it would do 19:49:13 <Sjoerd> you could use information from the schema to get more consistent results 19:50:09 <sbp> which schema? Atom's XML or RDF schema? 19:50:23 <Sjoerd> xml 19:50:28 <danbri> irc spam warning: [[ 19:50:29 <danbri> <feed rdf:parseType="Resource" xmlns="http://purl.org/atom/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> 19:50:29 <danbri> <title xmlns="">dive into mark 19:50:29 http://diveintomark.org/ 19:50:29 2003-08-05T18:30:02Z 19:50:29 19:50:31 19:50:35 Mark Pilgrim 19:50:37 ]] 19:50:56 xmlns="": ew 19:51:14 this is the output of XT, when fed my 2nd example... 19:51:17 Sjoerd: what do you mean--as in sucking up the datatypes? 19:51:22 which i changed per sam's advise just now. 19:52:06 f.e. when you have simpleContent with optional attributes, then you could use rdf:value even when there are no attributes in the xml 19:52:11 drop xmlns= 19:52:11 the children are NOT supposed to be in the atom namespace 19:52:11 which ns are they in? 19:52:11 "" 19:52:15 * danbri and maxf puzzle over this 19:52:27 * sbp looks at soap2rdf2.xsl 19:52:48 Sjoerd: ooh, I see. that's a very good point 19:53:19 we wait to hear from Sam how we can use default ns yet somehow associate those elements w/ Atom (without actually using XML namespaces properly). Very confused by this, but willing to learn... 19:53:46 * danbri goes to grab some food 19:53:52 danbri: where's the SOAP of the example whose output you just fed us? 19:54:02 * sbp decides that might be a good idea for him, too 19:54:09 linked from v end of http://esw.w3.org/topic/SpotOfDrama 19:54:32 i just edited it to meet this new constraint from sam, so maxf's stylesheet is treating it oddly 19:55:17 what if you give the atom ns a prefix 19:55:58 I think that'd count against our goal of having something simple enough to woo the Atom folks who don't like RDF's apparent verbosity 19:56:19 max says his xslt could bolt back on a ns to 'title' etc., if we knew the rule for where to get it 19:59:34 http://www.w3.org/2003/08/SOAPRDF/soapAtom-1-image.png is what we're aiming at anyways... 20:00:30 I'm back. 20:01:25 all you need to do is change two lines: 20:01:43 20:03:26 I was looking at ...Atom-1.xml 20:03:33 Atom-2.xml is OK 20:03:34 how is atom-2.xml now? 20:04:09 Thinking about it, Person should be a atom:Person. It seems more likely that an Atom:Person would reference things from a foaf namespace than the other way around. 20:04:20 soapAtom-1-image.png: can you make the link and id values into URIs? 20:04:28 its ok for soap tools, but its a bit odd for our convertificator... 20:04:43 how is anything supposed to know which namespace/vocab/etc 'title' etc comes from? 20:05:19 * rubys notes that he didn't choose to base this example on soap encoding... 20:05:34 maybe we could forget the *:Person type for now; I expect thats where most of the soap/rdf culture clash will happen 20:05:39 heh yeah, not your fault Sam! 20:06:06 basically, following the Atom debate (and rss1 before that), and hearing constant demands for a prettier RDF syntax, I wanted to take a look at the options. 20:06:38 As a dutiful W3C employee, I couldn't really jump into advocating a new RDF Syntax WG without taking care to see what other graph encoding syntaxes we might have lying around in http://www.w3.org/TR/ 20:08:22 So, as the soap-2-rdfizer scoops through atom-2.xml and wants to associate 'link', 'modified' etc with Atom (despite their own ns being ''), we need a rule for telling the xslt where to find the ns URI to attach them to in the emitted RDF. 20:08:33 soapAtom-1-image.png: can you make the link and id values into URIs? 20:08:43 s/URIs/Resources/ 20:08:47 see discussion of anyURI above. Yes, basically, Max says he'll have a go at that. 20:08:54 cool 20:08:57 I thought he already had the code actually but appears I dreamt it. How sad! 20:09:20 plan is that: http://diveintomark.org/ or similar is enough to auto-map. 20:10:02 If we part company with SOAP 1.2 Encoding, and end up just doing Yet Another Unstriped RDF Syntax, that's not the end of the world. 20:10:16 I'm interested to see if it ends up being significantly more consise, pretty 20:10:53 danbri: have you checked out the EF yet? 20:11:27 danbri: what you ended up with would map to somebody calling a procedure thus: 20:12:06 feed("dive into mark","http://diveintomark.org/","2003-08-05T18:30:02Z",author,entry) 20:12:14 where author and entry are structures/objects 20:12:52 I think I saw some mails related to http://www.intertwingly.net/wiki/pie/ExtensibilityFramework and prev comments in the wiki aspiring in that direction, but hadn't read it yet 20:13:46 sbp is pushing in that direction 20:13:58 its a healthy direction 20:14:12 his latest is at http://infomesh.net/2003/atomef/atom.txt 20:15:08 rubys, that's for invocation; what about in terms of a returned value (if that makes sense) 20:15:22 re feed("dive into mark","http://diveintomark.org/","2003-08-05T18:30:02Z",author,entry) 20:17:01 * danbri bbiab 20:24:10 in most cases, returned value in RPC is a single element 20:24:51 what RPC also does is match names in the input and output... if there are names that are in both, this is supposed to map to an in/out parameters (presuming your language supports in/out parameters) 20:27:03 sbp: i was looking at atomef/atom.rdf and have a few questions... 20:27:29 I don't think that doublequoted is a datatype, it is more like a parseType.... 20:28:11 I thought title would map to: 20:28:37 <rdf:value>Atom Updates &amp; Ideas</rdf:value> 20:29:21 if it mapped to that, it'd lose the double-quoted information 20:29:29 at the moment, it maps to _:Entry :title "Atom Updates & Ideas"^^atom:doublequoted . 20:29:43 where "blargh"^^xsd:string is datatype syntax 20:30:58 it could feasibly be mapped to _:Entry :title [ :mode "doublequoted"; rdf:value "Atom ... Ideas" ] .--there'd be no problem in specifying that, I just think that it's not as good an approach 20:31:53 because the doublequoted mode is really a datatype. it's not XML, it's not HTML, it's not base64 encoded, it's not plain text--it's its own datatype 20:32:49 * danbri tries to remember the only thing he built w/ enc/rpc... 20:33:02 i think i returned an array of (apache-extension) hashtables... 20:33:08 and note that mode="base64" will map MAN98374912MNANA to "MAN98374912MNANA"^^atom:base64, although again that could be mapped to :title [ :mode "base64"; rdf:value "MAN98374912MNANA" ] if required 20:34:14 that would be plain wrong, a datatype is certainly better 20:34:21 (we could even map some of these to XML Schema datatypes) 20:34:28 I don't think of doublequote as a datatype, more like a means of escaping the characters to be expressed... in essence an artifact of the framework, not a essential aspect of the data 20:35:12 Atom parsers can certainly handle it that way 20:35:16 another way of looking at it is that I can chose to express the exact same information in three different ways: inline, escaped, or base64 20:35:31 hmm 20:35:53 whereas the mime type is an essential property of the data 20:36:40 I think literals in rdf are kins of a serialized form of the data 20:37:00 KevinMarks has joined #echo 20:37:05 Sjoerd: from what I can see, I can express the same thing using literal and escaped in RDF 20:37:54 yes, and you'd have to know which one you used 20:38:08 I do? I'm trying an experiment now... 20:38:49 what combination of (inline|escaped|base64) and MIME types do you expect to be allowed for //title|summary? 20:38:59 the string in the rdf database is exactly what you have between and in the xml source 20:39:31 sbp: in the framework *I* thought we were talking about last night, I thought that these would be allowed for *any* string value 20:39:47 rubys, back re the soapenc thing, is it solely the 2nd layer of elements that has the ns='' constraint? 20:39:48 any combination that's also allowed in the xml 20:39:59 if the MIME type is implicit--and it must be if there's no type attribute that provides that information--then the MIME type can be a property of the //title element/rdf:Property 20:40:16 rubys: they can be. all of this is flexible 20:40:41 I wrote a stylesheet last night that did exactly that, and then I decided that datatypes would be better. if they're not, they're not, and that's fine 20:41:42 (hmm, http://www.w3.org/TR/soap12-part2/#datamodel really seems to try quite hard to not be RPC-specific...) 20:42:12 I haven't looked much at soap12 20:43:17 they made a huge rewrite of that bit of the spec, but i think soapenc's moment had passed by time it was finished... 20:43:36 OK, so the rules you just gave me w.r.t. namespaces etc might've been just for v1.1. 20:43:42 * danbri phews, mentally rewinds a bit 20:47:01 Sjoerd: it looks like you are right. Now, does anybody know why RDF insists on appending ^^http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral? 20:47:29 XMLLiteral == atom:mode="xml" 20:47:30 it does that when you have XML content in your rdf:parseType="Literal" block 20:47:33 yeah 20:47:45 I see that it does it, my question is: why? 20:48:34 * bitsko rereads for the context 20:48:52 When I wrote the following blosxom plugin: http://intertwingly.net/stories/2003/08/07/atom 20:48:54 see http://www.w3.org/2000/03/rdf-tracking/#rdfms-literal-is-xml-structure 20:49:32 ... I chose the 'best' way to represent the data based on whether it was well-formed or contained a problematic string. 20:49:40 In any case, the data is the same. 20:52:06 yes, and so is the string in the object part of the triple 20:52:25 that's why the mode has to be in the datatype 20:52:26 I'm beginning to nod, yes... 20:53:01 nodding yes to the data is the same, not the datatype. I too see mode of encoding as entirely seperate from datatype 20:53:05 In RDF, do I access the "string in the object part of the triple" the same way whether the data was represented as Literal or not? 20:53:25 rubys: depends on the toolkit. some will provide a DOM object for an XML literal 20:53:30 I understand that the data is the same kind of data after you parse it out of its (inline|escaped|base64) mode. I'm fine on that. but in the RDF model, the string won't have been parsed out of its mode, thus the mode information must be retained. the next question is what other information needs to be on there. does it need to have MIME information? if yes, rdf:value. if no, datatype 20:53:32 wait, I got that wrong 20:54:03 what sbp said 20:54:20 rdf tools are careful to avoid confusing (string)foo:blah and (uri)foo:blah, so you never need to sniff content to find URIs (and hence, to be able to merge data) 20:54:30 and that's what's happening at the moment. content goes to rdf:value because it has an @type denoting its mime type *and* an @mode for its mode. title only has @mode 20:56:15 So clients will have to write multiple code paths for each string attribute depending on how the provider decided to escape the data? 20:57:03 yep. rdf literals are that way 20:57:39 you can't unescape/unmode the literals in transformation 20:57:51 although very smart rdf databases could parse the string for you if they knew it is xml 20:58:08 yep. and as bitsko said, some provide a DOM for XMLLiteral, etc. 20:58:36 this all sounds distressingly heuristic 20:59:05 fwiw, I'd expect Atom toolkits to do the same: potentially provide a DOM for mode="xml" and a string for mode="escaped" 20:59:19 this would be a problem whether Atom used any type of transform or even full RDF/XML 20:59:42 feedparser.py will provide a single string in any case 20:59:59 having mutliple paths for content might be tolerable, but for every string element? 21:00:49 the only solution is to not allow multiple modes on //title 21:01:03 it has to be parsed out of its mode some time 21:01:15 or not allow mode=xml 21:02:10 or all strings are returned as a DOM textnode, but you probably wouldn't want that either 21:05:02 or, of course, to unmode at parse time. that'd be acceptable, just not possible in any XSLT 21:06:21 I can see XSLT being a good bet for a mapping--it's what we've all been gravitating towards, and it's what Sjoerd's implemented XR in and I've implemented the EF in and DanBri's used for his SOAP experiment. but personally, I'd use a SAX filter if there were any generic transformation 21:06:23 that would mean converting xml to a string, right? 21:06:52 not sure. I'm not sure what MIME types would be allowed for //title 21:06:57 I think the difference between EF and XR is that EF is generic and XR is application-specific. 21:07:26 * rubys notes that in SAX, one need not concern oneself with the difference between escaped and CDATA content 21:07:53 that's true about RDF too 21:07:58 * danbri reminds sbp that maxf did all the coding, i can barely read xslt 21:08:20 and xslt 21:08:22 if I use SAX, I could feasibly change the model at that time given datatypes passed to me. can't do that with XSLT 21:08:37 danbri: sorry. good work from you too, though 21:08:43 ta :) 21:08:51 a better term for "escaped" might be "characters", to distinguish from the possibility of mixed-content in mode "xml" 21:09:37 * rubys is not good at picking names. 21:10:39 the important question is: do we have an issue with the default mode for elements? title vs. content, for example. 21:11:39 the default mode being nothing--text/plain, no mode/escaping, plain undatatyped rdfs:Literal? 21:11:40 I'd like the default mode to work just fine for "Ben & Jerry's" 21:11:57 yep 21:12:20 Ben & Jerry's currently gets mapped onto :title "Ben & Jerry's" . 21:13:08 I still think that should be :title [ :rdf:value "Ben & Jerry's" ] 21:13:23 Rationalle: somebody will want to insert HTML into the title someday... 21:13:58 does xhtml's title element allow markup, i forget? 21:14:05 danbri: no 21:14:25 does h2? 21:14:30 yes 21:14:38 inline content only 21:14:54 what do you think a typical /feed/entry/title would map to in xhtml? 21:15:22

on my weblog 21:15:32 on Bray's 21:15:35 * sbp ducks 21:15:42 * rubys chuckles 21:16:35 on my weblog 21:16:44 impressive :-) 21:17:00 I'd still be happy using XHTML profile for weblog syndication, with a few class= etc... 21:17:07 Sjoerd: does allow markup in XHTML? 21:17:21 danbri: yeah... 21:17:44 rubys, yes inline markup 21:18:00 * bitsko just got himself confused again over escaped and double-escaped 21:18:41 when I do that, I just remind myself that <>& => "&", and things become clear again :-) 21:20:01 rubys: my thought is that because the MIME type is omitted from :title always, one can treat it as HTML all the time. so Ben & Jerry's would be HTML, and its RDF representation, :title "Ben & Jerry's" would be HTML 21:20:09 so I'd like the following mappings to occur... 21:20:33 it can't be html 21:20:38 "Ben & Jerry's" is not well formed. 21:20:46 right 21:21:19 "Ben & Jerry's" is well formed. 21:21:41 Ben & Jerry's => "Ben & Jerry's" 21:21:42 Ben & Jerry's => "Ben & Jerry's"^^rdf:XMLLiteral 21:21:42 Ben &amp; Jerry&apos;s => "Ben & Jerry's"^^atom:doubleescaped 21:21:57 hmm 21:22:02 aha. it's sbp, not me :) 21:22:13 there is no "double escaped". 21:22:43 current what Atom 0.2 calls escaped is what sbp calls doubleescaped. 21:23:20 yeah. I just call it double escaped because it's a nice way to remind people to do it twice. but it ties me in knots too... 21:23:42 Yoda: there is no "double escaped" 21:23:47 I did that once to prove to Aaron that he was wrong. It worked. ;-) 21:23:54 but it's confusing in the rdf context, because its only once escaped there 21:23:54 hehe 21:24:36 is there a consensus that the rdf:RDF/atom.dtd 21:24:36 "once escaped" is good. 21:24:36 my take is that doubleescaped maps to what rdf:value does natively 21:24:44 ...thing is cute but doesnt' work? 21:25:08 cute but isn't specification mandated, and probably won't work with most stuff 21:25:18 I don't think it works (as in, can't be made proper) 21:26:36 okay, so how do these differ: a) "Ben & Jerry's" b) [ rdf:value "Ben & Jerry's" ]; a) "Ben & Jerry's"^^rdf:XMLLiteral b) [ :mode "xml"; "Ben & Jerry's" ]; a) "Ben & Jerry's"^^atom:doubleescaped b) [ :mode "n-escaped"; "Ben & Jerry's" ] 21:26:49 yup. it would require lots of rdf tools to suddenly start working in care-about-dtds mode 21:27:00 rubys: rdf:value, itself, doesn't interpret things differently. that an RDF parser produces the same sequence of characters for mode="escaped" and mode="xml" (the latter with ^^rdf:XMLLiteral) is a coincidence. 21:27:18 eek, forgot a couple of rdf:values 21:27:29 sbp: the second a) is wrong, it's not valid xml 21:27:48 whoops, you're right. lemme start over. sorry 21:28:40 hmm 21:28:45 but it's what the RDF Validator does 21:28:49 the logical equivalency of :title "foo" and :title [ rdf:value "foo" ] is an RDF edge case 21:29:23 in that the latter *should* be interpreted the same as the former, but allows additional properties for the literal resource 21:29:30 input: 21:29:31 5: World Wide Web Consortium & 21:29:33 triple: 21:29:39 1 http://www.w3.org/ http://purl.org/dc/elements/1.1/title "World Wide Web Consortium &" 21:29:51 that seems ok 21:30:02 (it's left out the datatype, but there should be an ^^rdf:XMLLiteral on the end) 21:30:15 why? 21:30:27 in sbp's XSLT transform, specifically 21:30:35 eek, no. I'm wrong. ignore me. sorry 21:30:36 as to "why", that's what we're trying to decide 21:30:52 it's a plain string, not xml 21:30:57 yeah. got it 21:31:47 Sjoerd: yes, but World Wide Consortium in RDF *must* be an XMLLiteral 21:32:11 and sbp's transform can't (yet?) tell the difference 21:32:27 actually, it can 21:32:33 it can, mode="xml" makes it XMLLiteral 21:33:37 mode="xml" is also the default (no mode specified), in that case, World Wide Web Consortium & *should* be "World Wide Web Consortium &"^^rdf:XMLLiteral 21:33:49 sbp yesterday convinced me that we should make specifying the mode required if there are any nested elements. 21:34:11 I'm comfortable with that. 21:34:18 otherwise, the nested elements will be treated as properties 21:34:24 mode="xml" is not the default 21:35:00 for title at least 21:35:15 Sjoerd: contemplate: <strong>foo</strong> 21:36:05 sbp's goal is to allow a tool without an understanding of the application to distinguish where the literal content begins. 21:36:32 my goal is to allow Ben & Jerry's without any mode. 21:36:53 sure 21:36:58 that's just a string 21:37:12 (what's the mode for that?) 21:37:22 mode="xml 21:37:24 " 21:37:47 ah, hence the confusion 21:37:58 something I am willing to live with that will make sbp happier is to require mode="xml" be specified if one wanted to make Ben 21:38:02 mode="string" should be the default maybe 21:38:47 mode=string would be OK with me. 21:39:30 * bitsko must have been too early when *he* suggested requiring mode="xml" to signal mixed content ;) 21:39:49 what should @mode='string' map to? an untyped literal? 21:39:56 yes 21:40:30 that's what it does at the moment (when @mode is omitted, it defaults to that. it could support explicit @mode='string' too) 21:40:33 or ^^xsi:string 21:40:45 yeah. I've been wondering about mapping our strings to XSD 21:40:46 one reason we wanted to make mode="xml" the default was because, in five years, we don't want mode="escaped" being used anywhere except ancient archives. 21:41:08 to be clear: is there a difference between an untyped literal and XMLLiteral? 21:41:09 but mode="string" != mode="escaped" 21:41:11 we==a previous discussion 21:41:37 how is mode="string" != mode="escaped"? 21:41:53 string=escaped once. 21:41:54 it doesn't allow escaped markup 21:41:59 Sjoerd: yes. the first character of "

q

" is "<". the first character of "

q

"^^rdf:XMLLiteral is "q" to datatype aware RDF tools 21:43:53 who's the keeper of the scorecard? 21:44:04 * sbp votes for danbri 21:45:26 sillygwailo has joined #echo 21:45:38 as I understand it, this is the current status:- 21:45:38 Ben & Jerry's => "Ben & Jerry's" OR [ rdf:value "Ben & Jerry's" ] 21:45:38 Ben & Jerry's => "Ben & Jerry's"^^rdf:XMLLiteral OR [ :mode "xml"; rdf:value "Ben & Jerry's"^^rdf:XMLLiteral ] 21:45:39 Ben &amp; Jerry&apos;s => "Ben &amp; Jerry&apos;s"^^atom:nescaped OR [ :mode "nescaped"; rdf:value "Ben &amp; Jerry&apos;s"^^rdf:XMLLiteral ] 21:46:20 and we're not quite decided on which to use. but I think we've made a lot of forward motion on being clear what the difference between all the types and escapes are 21:46:31 a 21:46:31 <[CDATA[a]]> 21:48:35 sbp: is this an intentional difference from 0.2 snapshot or a misunderstanding? 21:49:01 intentional difference == proposal 21:49:47 gluon has joined #echo 21:49:57 the 0.2 snapshot used a essentially, didn't it? 21:50:41 sillygwailo has left #echo 21:51:45 d'oh! I see the miscommunication. again, the issue is not the encoding. repeat, *not* the encoding. there is no "double encoding". none. 21:53:15 there is: &amp; 21:53:57 the difference is between Ben & Jerry's and Ben & Jerry's 21:54:51 scratch that. lemme try again: 21:55:13 i'm glad that you are scratching that. 21:55:33 a 21:55:33 <[CDATA[a]]> 21:55:34 okay. we can make mode="escaped" map to a plain (non-datatyped) literal and mode="xml" map to an XMLLiteral; and use of rdf:value is optional there, to appease Sam :-) 21:55:35 they were correct btw 21:56:10 hmm 21:56:27 is type the type of the content after the mode has been parsed out, or before? I'm presuming after 21:57:03 bitsko: try doing Ben & Jerry's in escaped HTML. 21:57:18 sbp: you'll have to give examples, or else we'll misunderstand 21:57:19 you end up with such things as &amp; 21:57:39 the following are all equivalent: 21:57:41 Ben & Jerry's 21:57:41 <[CDATA[Ben & Jerry's]]> 21:57:41 Ben & Jerry's 21:57:41 <[CDATA[Ben & Jerry's]]> 21:58:12 bitsko: I disagree. Try doing the same foursome for text/html. 21:59:50 * Sjoerd starts to see why Userland can't get the escaping right in Radio 22:01:02 Ben & Jerry's 22:01:02 <[CDATA[Ben & Jerry's]]> 22:01:02 Ben &amp; Jerry&apos;s 22:01:02 <[CDATA[Ben & Jerry's]]> 22:01:52 ok, I agree with this foursome. Given this, I would suggest that the text/plain examples get updated. 22:03:11 updated how? text/plain has no "&" entities 22:03:30 mode="xml" is invalid for text/plain? 22:03:53 Sjoerd: it isn't just Userland. As this is completely unspecified in RSS, it is impossible for anybody to do better than guess. 22:04:07 Sjoerd: not invalid, just not useful with mixed content 22:04:32 perhaps we SHOULD add a mode="string". And make this the only valid value for mode for type="text/plain" 22:04:57 agreed. it doesn't make any sense otherwise 22:04:59 ok, now *that's* something we can put on a scorecard and talk about :) 22:05:37 if we're starting to make this easy, why not call mode="escaped" mode="html" 22:07:04 so we're starting to say that types are now inherent in modes? mode="string" implies a text/plain MIME type, mode="html" implies text/html, and mode="xml" implies XML 22:07:26 I'm not thrilled with such implicit knowledge. 22:07:44 And I don't see a problem with well formed HTML to be expressed with mode="xml" 22:07:57 that's what I was trying to get at earlier. modes and types are (currently) seperately specified (in , explicitly, I'd still been of the mind that would follow) 22:08:19 <Sjoerd> html in mode="xml" is xhtml 22:08:32 <bitsko> Sjoerd: not true 22:08:34 <sbp> that'd require having two attributes... 22:08:54 <Sjoerd> html 4.01 doesn't have <br/> but <br> 22:09:21 <jcgregorio> jcgregorio has joined #echo 22:11:46 <Sjoerd> I want to call mode=escaped mode=html because &amp; only makes sense with escaped html 22:12:21 <bitsko> let me characterize it differently, since yes, HTML prior to XHTML is not, by definition, XML. mode="xml" is a way of saying "this element may contain mixed content". <content type="text/html" mode="xml"> means the mixed content draws its vocabulary from pre-XHTML HTML, but is represented in mixed-content mode 22:12:58 <sbp> it makes sense with escaped XML, too. but the only practical use is for broken HTML. I can see people using mode="escaped" for XHTML too, though, just because they fear having made an error 22:13:24 <bitsko> *if* we want to exclude pre-XHTML from using mode="xml", I'd stubbornly agree to it as not being "technically correct". 22:13:58 <sbp> can you give us a full example of what <content type="text/html" mode="xml">, using pre-XHTML 1.0, would look like, please? 22:14:33 <bitsko> sbp: it looks like XHTML. 22:14:58 <rubys> <content type="text/html" mode="xml">hello world</content> 22:15:08 <sbp> I see 22:15:21 <rubys> <content type="text/html" mode="xml">Ben & Jerry's</content> 22:15:48 <Sjoerd> now something that isn't valid XHTML 1.0 22:15:58 <Sjoerd> but valid HTML 4.01 22:16:11 <rubys> <content type="text/html" mode="xml"><b><i>Ben & Jerry's</b></i></content> 22:16:19 <rubys> nope 22:16:27 <rubys> scratch that 22:17:22 <Sjoerd> I know one 22:17:40 <Sjoerd> <content type="text/html" mode="xml"><B>Ben & Jerry's</B></content> 22:18:12 <rubys> XHTML is also stricter as to the DTD 22:18:41 <rubys> In HTML I had forms with inputs. In XHTML, I had to add <div>s 22:19:25 <Sjoerd> those are required in HTML 4 also 22:19:42 <sbp> note that your <B> is in the atom namespace in that example 22:20:22 <Sjoerd> hehe, well, what namespace should it be then? 22:20:56 <sbp> exactly :-) 22:20:58 <bitsko> ah, I think that's the case that excludes text/html from mode="xml" 22:21:39 <bitsko> when you have to declare the element's namespace. it'd have to be XHTML at that point. 22:21:39 <Sjoerd> great find, sbp! 22:23:16 <sbp> thanks 22:23:38 <sbp> * sbp is absorbing all of this; it'll be fun when we have to specificationalize it all 22:23:43 <bitsko> maybe content's mode or type shouldn't be reused for title. 22:24:26 <bitsko> what's the XPath syntax for an element and it's attribute? //content@mode? 22:24:36 <sbp> //content[@mode] 22:24:50 <Sjoerd> what do you mean with "and" 22:25:14 <bitsko> sbp got what I was lookign for 22:25:42 <sbp> that selects the element as a note, though, note 22:25:49 <sbp> s/note/node/ 22:26:08 <bitsko> in content, @mode and @type are being used because content can almost literally be any media type. in title and most other cases, there are only a very few types I think we're looking for. 22:26:08 <sbp> //content/@mode selects the attribute 22:26:21 <bitsko> s/almost// 22:27:05 <sbp> agreed 22:27:09 <bitsko> reusing @mode on <title>, therefore, is mixing their uses 22:28:06 <sbp> that's why I'd been asking what ranges of MIME types (and "encodings"/modes) would be allowed for //title and //summary 22:28:18 <bitsko> the problem, as we all probably know, is non-wellformed data, not XMLLiteral vs. string 22:29:10 <Sjoerd> that might be a problem too, but let's first get this right without getting into rdf 22:29:31 <sbp> +1 22:30:34 <bitsko> as I see it, there are only three combinations of type+encoding for non-<content>: plain text, html escaped, html inline 22:32:06 <sbp> agreed. though the xhtml/html distinction is fuzzy. plain text, xhtml/html escaped, xhtml inline to be pedantic 22:32:08 <Sjoerd> xhtml inline 22:32:23 <bitsko> yes, thx 22:32:56 <Sjoerd> plain text is default 22:33:08 <Sjoerd> xhtml inline is mode="xml" 22:33:29 <bitsko> of course, we could probably simplify Atom greatly by reducing <content> to just those three as well, and using MIME (8-bit clean, even!) for multipart and other media types. 22:34:23 <Sjoerd> other xml like svg is also ok for content 22:34:48 <sbp> what about atom for content? :-) 22:35:17 <sbp> now, wouldn't *that* be confusing? it's an edge case we might well want to be aware of, though 22:35:21 <rubys> * rubys or rss 22:36:09 <sbp> heck, if you can use URIs to import content, you can have a feed cyclically including itself 22:36:22 <KevinMarks> KevinMarks has joined #echo 22:36:27 <bitsko> * bitsko points at <content src="..."> 22:37:03 <bitsko> where'd we put the XML test case list? :) 22:37:48 <sbp> I recall that; s'where I got the idea from... 22:38:58 <bitsko> Sjoerd: <Sjoerd> xhtml inline is mode="xml" -- what do we use for plain text or x/html escaped? 22:39:30 <rubys> * rubys notes that there's a lot of "xhtml" which is not well formed. 22:39:40 <Sjoerd> mode="escaped" currently, I still like mode="html" 22:40:08 <rubys> what I don't like about mode="html" is that people will assume that that is what they have to use to make a word bold in a title. 22:40:45 <sbp> * sbp reads http://www.intertwingly.net/blog/1568.html and recognizing the paving of the way for complex content for //title... 22:41:06 <rubys> * rubys smiles 22:41:20 <Sjoerd> ok, let's make it mode="bad(x)html" then 22:42:21 <sbp> s/nizing/nizes/ 22:42:35 <sbp> this is all connotative stuff, though, right? we're all agreed on what mode="html|escaped|whatever" means? 22:43:17 <Sjoerd> I think so 22:43:22 <sbp> we've still got the problem, as bitsko put it, that //content needs a MIME type and a mode, whereas //title can get away with having a small enumeration--just three possibilities 22:43:42 <Sjoerd> it means: title.nodeValue = h2.innerHTML 22:44:04 <bitsko> if @mode defaults to "xml" and @type defaults to "look at the namespace of the xml element(s)", we could reuse the <content> @mode and @type generically for any element, and let the validator clean things up. 22:44:16 <Sjoerd> that should be title.firstChild.nodeValue 22:45:01 <sbp> @type is pretty redundant with @mode='xml', agreed 22:45:22 <sbp> it's also redundant with @mode='escaped', of course: text/html 22:45:28 <bitsko> unless @type is svg... 22:45:38 <sbp> and with @mode='string', text/plain 22:45:46 <sbp> granted, and with RSS technically, and XML/RDF, etc. 22:45:55 <sbp> and XHTML especially 22:46:00 <sbp> but I've never really got that 22:46:02 <Sjoerd> with @mode='string' it could be CSV 22:46:33 <sbp> registering MIME types for XML content seems like an overkill, but it's something which has been generally accepted now... 22:46:35 <Sjoerd> or any other text/* mimetype 22:46:50 <sbp> would it be better to say that, then? 22:47:17 <sbp> * sbp says more to himself than anyone else 22:48:05 <sbp> okay. so we seem to have done a 180. are we agreed that even when the @mode is known, you can't assume the @type? 22:48:16 <sbp> you can have a rough idea... 22:49:09 <bitsko> do you mean @mode as in Atom0.2 or @other_mode as we've been discussing? the former doesn't distinguish between text/plain and text/html 22:49:11 <sbp> for any value of @mode, too, except perhaps @mode='escaped' 22:49:47 <sbp> @mode in the guise of an attribute which gives the encoding/escaping/mode/feel/quoting only of the content 22:50:29 <bitsko> lets give a different name for now, to distinguish from //content/@mode 22:50:37 <sbp> okay 22:51:08 <sbp> (though I think that //content/@mode does do that, since an @type is required there) 22:51:28 <bitsko> specifically, because @mode=escaped means characters (#PCDATA), not double escaping 22:51:31 <gluon> gluon has left #echo 22:51:59 <bitsko> and escaping vs. double escaping is what distinguishes text/plain from text/html 22:52:01 <sbp> okay 22:52:11 <sbp> yes, fair point 22:53:26 <sbp> what I'm working towards is that we should a) have a clear specification of @mode b) a clear specification of @type, and hoping that we'll find that we can have a third property that allows some combinations of those two attributes as an abbreviation 22:54:15 <sbp> I think I'm clear now on what @mode's purpose is, though I'm having trouble expressing it very sharply, and @type is obviously a MIME type 22:54:25 <bitsko> the wiki ["content"] page should be clear on (a) and (b), except that mode="xml" is the default. 22:55:06 <rubys> mode="string" is the default? 22:55:10 <sbp> * sbp re-reads ["content"] 22:55:28 <Sjoerd> rubys: for title, not for content 22:55:42 <bitsko> what I'd like to consider is two options, 1) a new attribute for non-<content>, 2) allowing <content>'s @mode and @type on any property, with the defaults being "xml" and "look at the namespace". 22:55:48 <sbp> mode="string" as default: I think it should be the default everywhere, yes 22:55:48 <rubys> I'd like the mode default the same across all elements 22:56:27 <rubys> the more I think about it, double escaping shouldn't be illegal for text/plain, merely not particularly useful. 22:56:36 <bitsko> 2b) restricting the range of @mode or @type via schema and docs 22:57:53 <sbp> 2b)--if you're talking about the RDF model for all this, that's a lot trickier... 22:58:15 <bitsko> I think the RDF model will be clear once we make the Atom model clear :D 22:58:20 <sbp> yeah 22:59:45 <sbp> 2) isn't going to work 22:59:59 <sbp> because if those are the defaults, what's the namespace in <title>something? 22:59:59 * Sjoerd was thinking the same 23:00:05 i.e., what is the type of "something"? 23:00:15 you say to look at the namespace: what namespace? 23:01:32 so in that case, you'll end up defaulting to something weird, or you'll have to use 1) 23:01:38 an XML Characters node is just characters. we can specify the interpretation of that in the model. 23:02:38 so it'd be suitable for use in HTML, but not HTML specifically? 23:02:46 specifically, the model for is "text to display as the title of a feed or entry, plain text or X/HTML only" 23:03:32 <bitsko> since it's just characters with no mixed content, it can be treated either as plain text or markup, the result is the same. 23:03:36 <sbp> the model for when there's no namespace available, you maen? because you couldn't display arbitrary XML, but it would be allowed 23:03:45 <bitsko> for no namespace, yes 23:03:49 <sbp> okay 23:04:38 <sbp> and the defaults would apply on //content too? 23:04:41 <bitsko> hmm, for XML Character Data, which by definition has no namespace. distinct from an XML Element Node, which must have a namespace to be interpreted properly 23:05:04 <bitsko> I would think so, yes, to be consistent. 23:05:42 <sbp> so what about a <title><svg ...>...</svg> case? what's the MIME type of the content, and how do you find that out? you expect people to map from namespaces to MIME types? 23:06:04 there's a balance between being overzealously consistent and human readable, but I think we're doing well so far. 23:06:20 yes 23:06:29 dajobe has left #echo 23:08:00 there is a difference between mode="string" and mode="xml" with character content only 23:08:21 the programming interface would either return a string or a dom textnode 23:08:44 yes 23:09:09 and mode="string" will require a @type 23:09:10 given the oft requested feature of allowing any XML content, I doubt many will have MIME types. 23:09:32 why would mode="string" require @type? 23:09:50 foo should be legal... 23:09:53 * danbri heads off, happy haacking folks! 23:09:56 well, unless it were defaulted to something 23:10:02 and thanks for the soap wisdom sam :) 23:10:02 cu 23:10:06 but bitsko was asking for @mode='xml' to be the default 23:10:08 c'ya danbri! 23:10:14 c'ya 23:10:15 thanks for hanging around here 23:10:23 * danbri will be back :) 23:10:28 bye! 23:10:31 danbri has left #echo 23:11:18 * bitsko notes that requiring the @mode='xml' be explicit for mixed content is also ok/good 23:11:21 @mode='xml' as the default breaks the ability to disambiguate data without knowledge of the schema. 23:11:33 for elements other than content, mode="string" and type="plain/text" should be the default 23:11:43 ooh. true 23:12:24 Sjoerd: if we can, I'd rather content not be special. What's the harm in having mode="string" and type="text/plain" as the default for content? 23:12:46 * sbp nods 23:12:55 none, I said nothing about defaults for content :) 23:13:55 so we're back to the compact @mode/@type expression idea 23:15:09 a required mode='xml' for mixed content disambiguates data from data 23:16:20 @mode='string' and @type='text/plain' as default everywhere. for //title, only (@mode='string' and @type='text/plain'), (@mode='xml' and ???), and (@mode='escaped' and @type='text/html') are allowed 23:16:59 You mean I can't have Prince's former symbol as a title? ;-) 23:17:03 what, precisely, is mode="string"? 23:17:22 heh. you can lobby unicode to include it in the next release 23:17:39 bitsko: mode="string" == mode="xml" with the added constraint that no non-text nodes are allowed 23:17:55 @mode may signal that the content should be returned programmatically as a string instead of a DOM node, too 23:18:01 and it will have RDF model ramifications 23:18:30 k. "string" == #PCDATA, "xml" == ANY 23:18:39 bitkso: +1 23:18:41 looks good 23:19:35 that gives a good excuse for requiring mode="xml" as a signal for parsing or transforming mixed content, too ;) 23:21:07 these restrictions can be put in relaxng too 23:21:52 hmm, now what distinguishes "string" from "escaped", besides a @type? 23:21:53 <em>I'm important</em> would not validate, but <em>I'm important</em> would 23:22:36 bitsko: that is hard to distinguish programmatically 23:22:43 nothing, except the way it has to be rendered in an html document 23:23:05 so... we should have test cases for aggregators to ensure that they display such content properly. 23:23:43 are there any aggregators supporting an Atom module yet? 23:23:51 and when the atom validator sees < it has to ask if a < in the title is the desired effect 23:24:05 two or three. Newsgator, Clever Cactus, at least. 23:24:34 radio can load atom 0.1 23:25:08 I need to nag Joe to get Aggie on board. ;-) 23:25:13 re. string vs. escaped, note that I've equated "escaped" to "just characters" from the beginning. if this were an HTTP/MIME entity, I'd say "octets" 23:26:23 Ben & Jerry's =>

Ben & Jerry's

, Ben &amp; Jerry's =>

Ben & Jerry's

, am I correct? 23:26:30 escaped is really only for html that's not xhtml 23:26:47 escaped is really only for html that is not well formed xml. 23:27:11 and therefore not xhtml 23:27:35 but I can see people escaping their XHTML "just in case" 23:27:59 then it's not xhtml 23:28:04 but in that case, it must still be tr... yeah 23:28:15 treated as tag soup, aka. text/html 23:28:47 you can't call something xhtml that is not guaranteed to be xml 23:29:17 accepted 23:29:59 the difference between Ben & Jerry's and Ben &amp; Jerry's is that the former is text/plain and the latter is text/html, or did I miss something? 23:30:46 * Sjoerd would really like to stick around, but has to go to sleep to have any chance of arriving at work on time tomorrow 23:30:48 emanu has joined #echo 23:31:42 right 23:32:06 Netmonger has joined #echo 23:32:08 I'll see the results in the logs, ggod night! 23:35:32 the former isn't necessarily text/plain. it depends; we can say that mode="string" and no @type means that it defaults to text/plain. I think that's what we're thinking about now 23:35:44 the latter has to be text/html, though, yes 23:38:44 @mode="escaped" forces text/html. @mode="xml" defaults to "check out the namespace", and @mode="text" defaults to text/plain 23:39:30 @mode="xml" can occur with other @type values, @mode="text" can occur with other @type values, @mode="escaped" cannot meaningfully do so, although Sam proposed allowing this some time ago, IIRC 23:40:38 Ben & Jerry's 23:40:38 <[CDATA[Ben & Jerry's]]> 23:40:38 Ben & Jerry's 23:40:38 <[CDATA[Ben & Jerry's]]> 23:40:38 Ben & Jerry's 23:40:38 <[CDATA[Ben & Jerry's]]> 23:40:43 23:40:44 Ben & Jerry's 23:40:46 <[CDATA[Ben & Jerry's]]> 23:40:48 Ben &amp; Jerry&apos;s 23:40:51 <[CDATA[Ben & Jerry's]]> 23:40:52 Ben &amp; Jerry&apos;s 23:40:54 <[CDATA[Ben & Jerry's]]> 23:42:16 hmm 23:43:41 it'd be nice if we could end up with a canonicalized form out of these. a MIME type and a set of octets, aka a string? 23:44:19 I guess I'm still not seeing the benefit of string *and* escaped. let's replace escaped with string. or not. 23:44:59 but I think that they'd map differently to HTML. the example I gave earlier: Ben & Jerry's =>

Ben & Jerry's

, Ben &amp; Jerry's =>

Ben & Jerry's

23:47:32 you can't specify broken HTML in @mode='string', I think 23:48:56 oh, lightbulb. I think I see your point 23:49:49 since @mode='string' is #PCDATA, you can't embed XML directly anyway, so it has to be escaped, so there's no point in having an @mode='escaped', yes? 23:50:21 sbp: not exactly 23:50:46 Ben & Jerry's 23:51:09 Ben &amp; Jerry&apos;s 23:51:20 Ben & Jerry's 23:52:05 ah. so #PCDATA HTML in a #PCDATA @mode doesn't have to be escaped... gotcha 23:52:35 exactly. String is more like xml. 23:52:44 just restricted. 23:53:49 bitsko: what do you feel about that? 23:54:48 Ben & Jerry's 23:54:48 <[CDATA[Ben & Jerry's]]> 23:54:48 Ben & Jerry's 23:54:48 <[CDATA[Ben & Jerry's]]> 23:54:48 Ben &amp; Jerry&apos;s 23:54:49 <[CDATA[Ben & Jerry's]]> 23:55:06 (missing a ; in the first "string" example) 23:55:40 I think they're all equivalent 23:57:41 (missing a ! in the second line) 23:58:13 all six look equivalent to me 23:58:49 the mode="escaped" has &amp; 23:59:17 after unescaping, it disappears. after unmoding