Chatlog 2012-05-09

From RDF Working Group Wiki
Revision as of 16:45, 9 May 2012 by Eric (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

See panel, original RRSAgent log or preview nicely formatted version.

Please justify/explain non-obvious edits to this page, in your "edit summary" text.

14:36:24 <RRSAgent> RRSAgent has joined #rdf-wg
14:36:24 <RRSAgent> logging to
14:36:26 <trackbot> RRSAgent, make logs world
14:36:26 <Zakim> Zakim has joined #rdf-wg
14:36:28 <trackbot> Zakim, this will be 73394
14:36:28 <Zakim> ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start in 24 minutes
14:36:29 <trackbot> Meeting: RDF Working Group Teleconference
14:36:29 <trackbot> Date: 09 May 2012
14:55:27 <AZ> AZ has joined #rdf-wg
14:55:44 <Zakim> SW_RDFWG()11:00AM has now started
14:55:58 <Zakim> +??P3
14:55:58 <Zakim> + +31.20.598.aaaa
14:56:05 <Guus> Guus has joined #rdf-wg
14:56:23 <yvesr> Zakim, who is on the phone?
14:56:23 <Zakim> On the phone I see ??P3, +31.20.598.aaaa
14:56:26 <pchampin> pchampin has joined #rdf-wg
14:56:27 <yvesr> Zakim, ??P3 is me
14:56:27 <Zakim> +yvesr; got it
14:57:07 <Guus> zakim, +31.20 is me
14:57:07 <Zakim> +Guus; got it
14:57:19 <ivan> zakim, dial ivan-voip
14:57:19 <Zakim> ok, ivan; the call is being made
14:57:20 <Zakim> +Ivan
14:57:38 <Guus> zakim, this is RDF
14:57:38 <Zakim> Guus, this was already SW_RDFWG()11:00AM
14:57:39 <Zakim> ok, Guus; that matches SW_RDFWG()11:00AM
14:58:35 <ScottB> ScottB has joined #rdf-wg
14:58:47 <Zakim> +??P7
14:58:52 <AndyS> zakim, ??P7 is me
14:58:52 <Zakim> +AndyS; got it
14:59:14 <PatH> PatH has joined #rdf-wg
15:00:04 <Zakim> +bhyland
15:00:13 <davidwood> Zakim, bhyland is really me
15:00:13 <Zakim> +davidwood; got it
15:00:28 <Zakim> +??P8
15:00:49 <pfps> pfps has joined #rdf-wg
15:01:01 <Zakim> +OpenLink_Software
15:01:05 <Zakim> +Tony
15:01:09 <pfps> zakim, ??p8 is me
15:01:09 <Zakim> +pfps; got it
15:01:13 <pfps> ack ??p8
15:01:21 <ScottB> Zakim, Tony is temporarily me
15:01:21 <Zakim> +ScottB; got it
15:01:31 <AZ> I'm the scribe, I'm joining the call
15:01:39 <MacTed> Zakim, OpenLink_Software is temporarily me
15:01:39 <Zakim> +MacTed; got it
15:01:40 <MacTed> Zakim, mute me
15:01:40 <Zakim> MacTed should now be muted
15:01:47 <Zakim> +??P15
15:01:52 <Zakim> +gavinc
15:01:56 <tbaker> tbaker has joined #rdf-wg
15:02:12 <AZ> Zakim, ??P15 is me
15:02:12 <Zakim> +AZ; got it
15:02:30 <PatH> I will be joining on IRC today but can call in if absolutely needed.
15:02:38 <Zakim> +??P19
15:02:53 <Zakim> +??P18
15:03:02 <danbri_> zakim, ??P18 is probably danbri
15:03:02 <Zakim> +danbri; got it
15:03:03 <tbaker> zakim, ??P19 is tbaker
15:03:04 <Zakim> +tbaker; got it
15:03:30 <AZ> scribe: AZ
15:03:35 <Zakim> +Sandro
15:04:10 <Zakim> +mhausenblas
15:04:14 <cygri> zakim, mhausenblas is temporarily me
15:04:14 <Zakim> +cygri; got it
15:04:17 <davidwood> Topic: Admin
15:04:20 <davidwood> PROPOSED to accept the minutes of the 2 May telecon:
15:04:20 <davidwood>
15:05:13 <davidwood> Review of actions
15:05:13 <davidwood>
15:05:13 <davidwood>
15:05:55 <Zakim> + +
15:06:07 <pchampin> zakim, aabb is me
15:06:08 <Zakim> +pchampin; got it
15:06:30 <gavinc> Closed ACTION-168 as a duplicate
15:06:36 <sandro> I've made no progress on any of mine, sorry.
15:07:41 <davidwood> Topic: XMLLiteral
15:07:47 <cygri> q+
15:07:55 <davidwood> See proposal at:
15:07:55 <davidwood>
15:08:00 <davidwood> ack cygri
15:08:13 <cygri>
15:08:17 <Zakim> +ericP
15:08:46 <MacTed> Zakim, who's noisy?
15:08:48 <LeeF> LeeF has joined #rdf-wg
15:08:56 <Zakim> MacTed, listening for 10 seconds I heard sound from the following: davidwood (8%), AZ (14%), ericP (15%)
15:09:14 <ericP> scribenick: ericP
15:09:17 <Zakim> +LeeF
15:09:28 <ericP> cygri: the lexical space need not be canonical, btu well-formed
15:09:43 <davidwood> • Make rdf:XMLLiteral optional in the datatype map
15:09:43 <davidwood> • Change rdf:XMLLiteral lexical space to allow
15:09:43 <davidwood>   non-canonical but well-formed XML
15:09:43 <davidwood> • Define a canonical lexical form for rdf:XMLLiteral
15:09:43 <davidwood>   that is equivalent to the old lexical space
15:09:44 <davidwood> • Re-define the value space in terms of XML infosets (this
15:09:46 <davidwood>   should be in 1:1 correspondence to the old value space
15:09:48 <AZ> AZ has joined #rdf-wg
15:09:48 <davidwood>   and old lexical space)
15:09:49 <ericP> ... then we can add a canonical lexical form, which is the same as the old lexical space
15:09:56 <gavinc> cygri: (describes rdf:XMLLiteral as found in link)
15:10:13 <ericP> ... the value space would be 1:1 on the old values space, but we would want to rephrase the definition
15:10:21 <ericP> ... there are two proposals:
15:10:31 <ericP> ... .. expresses it in terms of infosets
15:10:41 <cygri>
15:10:47 <ericP> ... .. and we've just looked at expressing it in terms of DOM trees
15:10:57 <ericP> ... DOM trees should be the same thing
15:11:28 <ericP> q+ to ask why DOM (defined in terms of DOM) instead of infoset
15:11:33 <Zakim> -pchampin
15:11:39 <ivan> q+
15:11:52 <ericP> cygri: question is how to define
15:12:19 <Zakim> ericP, you wanted to ask why DOM (defined in terms of DOM) instead of infoset
15:12:21 <davidwood> ack ericp
15:12:40 <zwu2> zwu2 has joined #rdf-wg
15:12:41 <gavinc> DOM is not phrased in term of the infoset
15:12:51 <zwu2> zakim, code?
15:12:51 <Zakim> the conference code is 73394 (tel:+1.617.761.6200, zwu2
15:13:31 <AZ> gavinc: XPath, XQuery, define their own data model
15:13:34 <AndyS> FYI,
15:13:50 <Zakim> +zwu2
15:13:54 <davidwood> ack ivan
15:14:06 <zwu2> zakim, mute me
15:14:06 <Zakim> zwu2 should now be muted
15:14:33 <ericP> gavinc: infoset has no conformance. all specs create their own model
15:14:39 <ivan> A.isEqualNode(B)
15:14:42 <ericP> ivan: we asked Liam, who said the same as gavinc 
15:15:07 <ericP> ... there is also a handy equiv function, A.isEqualNode(B), in DOM
15:15:30 <ericP> ... another issue is whether we want to have an HTML5 literal
15:15:48 <Zakim> + +
15:15:48 <ericP> ... HTML5 is defines how to parse HTML5 into a DOM
15:15:53 <pchampin> zakim, aacc is me
15:15:53 <Zakim> +pchampin; got it
15:15:56 <pchampin> zakim, mute me
15:15:56 <Zakim> pchampin should now be muted
15:16:14 <ericP> ... HTML5 does not go so far as how to say what HTML5 looks like in an infoset
15:16:31 <ericP> ... we can chain specs to derive that, but it's complicated and unnecessary
15:16:35 <davidwood> q?
15:16:49 <ericP> i'm happy for this choice as long as we have the blessing of Liam
15:17:01 <ericP> davidwood: is this what steve harris objected to?
15:17:18 <ericP> ivan: he had issues with the complexity
15:17:29 <cygri> q+
15:17:37 <davidwood> Ivan: We can define a path from an HTML5 literal to an infoset, but Steve had issues with that level of complexity in RDF.
15:17:38 <ericP> ... but it's not required that one implement the equiv
15:18:02 <PatH> FWIW, I am happy with anything as long as there is a well-defined literal-to-value mapping we can refer to in the semantics. 
15:18:11 <ericP> ... current defn demands that one create canonical XML
15:18:19 <davidwood> Ivan: Nobody knows what canonical XML is.
15:18:37 <ericP> ... if you have a tool, like my RDFaDistiller, you're stuck finding a c14n library
15:18:46 <AZ> s/Ivan:/Ivan,/
15:18:48 <cygri> q-
15:18:57 <gavinc> +q to add that it doesn't even have to be valid XML
15:19:17 <ericP> ... so with the DOM soln, if tools want equality, they can use the DOM function
15:19:32 <davidwood> ack gavinc
15:19:32 <Zakim> gavinc, you wanted to add that it doesn't even have to be valid XML
15:20:04 <ericP> gavinc: if defined in terms of DOM instead of XML C14N, we can leverage the HTML5 error handling
15:20:23 <ericP> ... this can help us consume non-well-formed markup
15:20:36 <gavinc> s/HTML5/XML
15:20:43 <cygri> q+
15:20:57 <gavinc> See
15:20:58 <davidwood> ack cygri
15:20:58 <ericP> davidwood: richard's proposal exists in the context of needing of an XML datatype
15:21:08 <ericP> ... so we can reduce the need for the XML datatype
15:21:26 <davidwood> s/needing of an XML datatype/needing of an HTML datatype/
15:21:30 <ericP> cygri: even if we don't change the effective datatype, a change to the defn makes it more usable
15:22:08 <ericP> ... we're not ready to propose HTML literals, issues around parsing, etc
15:22:17 <ericP> davidwood: but we've generally agreed that we'll do it
15:22:43 <ericP> cygri: even before that, i propose redefining the XML literal
15:23:03 <ericP> davidwood: make XML literal optional in the datatype map
15:23:12 <Zakim> +Arnaud
15:23:17 <davidwood> Change rdf:XMLLiteral lexical space to allow
15:23:17 <davidwood>   non-canonical but well-formed XML
15:23:21 <Arnaud> Arnaud has joined #rdf-wg
15:23:40 <ericP> ivan: XML literals are not necessarily meant to capture HTML5
15:23:50 <ericP> davidwood: we don't have an XHMTL type
15:24:04 <gavinc> XHTML is XML
15:24:12 <gavinc> HTML is HTML
15:24:21 <ericP> ... hope 
15:24:30 <ericP> s/... hope /
15:24:55 <gavinc> Polyglut documents are funky and only crazy people like Sam Ruby make them
15:25:09 <PatH> Wait. Good XHTML is XML< but can there be bad XHTML which is still good XML?? IF so, we need a separate datatype.
15:25:22 <gavinc> No, there is no such thing as "bad" XHTML
15:25:37 <ericP> davidwood: regardless of what we do with XML and HTML datatypes, some data could go in either
15:25:56 <PatH> Oh. Hmm, I guess I really should shut up at hthis point :-)
15:26:03 <ericP> gavinc: "Polyglut" meaning a document that is both application/xhtml and text/html
15:26:07 <ericP> ... those are hard to make
15:26:11 <gavinc> Polyglot too
15:26:31 <ericP> s/Polyglut/Polyglot/
15:26:52 <PatH> I like polyglut. I knew one of them once. 
15:27:34 <ivan> q?
15:27:38 <ericP> cygri: old XML value space is XML C14N, which specifies e.g. " vs. ', empty tags vs. tag pairs, etc.
15:27:39 <ivan> q+
15:27:44 <davidwood> ack ivan
15:28:06 <ericP> ivan: do we need this canonical lexical form for each datatype?
15:28:08 <PatH> Are there many users of rdf:XMLLIteral, in fact? 
15:28:55 <PatH> No, a dtatype does not *need* to hve a cononical form,. It just makes equality checking WAAAAY easier. 
15:29:20 <PatH> cononical/canonical
15:29:23 <gavinc> PatH, DOM defines equality checking
15:29:27 <ericP> ericP: use cases for any canonicalization are around e.g. SPARQL queries looking for shoe:size 5 and not shoe:size "05"^^xsd::integer
15:29:30 <AndyS> Users - yes and no.  GML literals are XML (but often not legal XMLLiterals)
15:29:31 <PatH> Well then fine.
15:29:44 <ericP> ... use cases for the XML Literal analog are a little bit of a stretch
15:29:50 <AndyS> q+
15:30:18 <ericP> ivan: responding to PatH, DOM-level equiv is easier than C14N equiv
15:30:48 <PatH> OK.
15:30:50 <davidwood> ack AndyS
15:31:13 <ericP> q+ to ask how equiv is used in anger
15:31:49 <ericP> AndyS: it's clear how canonicalization is used
15:32:11 <PatH> If you speak to me like that again., I'll equiv you so fast you won't know you've been canonicalized.
15:32:20 <ericP> ... c14n is more in favor of containing the complexity to input normalization
15:32:47 <ericP> ... unfortunetely, many XML literals can't just be pasted
15:33:02 <ericP> ... you've moved the problem to someone else
15:33:23 <PatH> +1 ericP
15:33:37 <pchampin> q+
15:33:37 <PatH> Or was it Andy. 
15:33:43 <ericP> davidwood: ok to push to someone else if the string is to be interpreted in someone else's application
15:33:56 <PatH> Gotcha
15:34:27 <ericP> gavinc: isn't there a clear optomization path?
15:34:42 <cygri> q+
15:34:52 <davidwood> ack ericp
15:34:52 <Zakim> ericP, you wanted to ask how equiv is used in anger
15:35:11 <ericP> AndyS: depends on whether you want the output to exactly reflect the input
15:35:46 <ericP> ... i'd like to encourage folks to canonicalize, but not oblige them
15:36:18 <ericP> davidwood, if we do input normalization, they incur a cost for a data element which may never be read [or matched -- ED]
15:36:24 <ericP> davidwood: if we do input normalization, they incur a cost for a data element which may never be read [or matched -- ED]
15:36:51 <PatH> Seems to me key issue is, if I don't coninicalize, will your queries work right against my data? And if not, whose fault is that?
15:36:58 <ericP> ... if you canonicalize on use, e.g. SPARQL, we impact those apps
15:37:25 <pchampin> zakim, unmute me
15:37:25 <Zakim> pchampin should no longer be muted
15:37:26 <davidwood> ack pchampin
15:37:28 <ivan> pat, if the query engine implements equality of the dom trees, then it should work
15:37:39 <ericP> ... it seems easier technically and socially to canonicalize on input
15:37:58 <ericP> pchampin: i agree with AndyS's point
15:38:18 <ericP> ... prob is folks won't necessarily know it's canonicalized and not take advantage
15:38:22 <PatH> Ivan, OK, then why are we discussing canonicalizing on input? 
15:38:27 <davidwood> ack cygri
15:38:33 <ericP> ... an option is to have two, one with a restricted lexical space
15:38:34 <ericP> cygri
15:38:39 <ivan> pat, I do not know, that was i was asking, too!
15:38:44 <ericP> cygri: that's what i proposed, but it's not working out
15:38:50 <PatH> Ah, pchampin makes good point.
15:39:00 <ivan> +1 to Richard
15:39:11 <ericP> ... i don't think that requiring canonicalization has worked out
15:39:18 <ivan> c14n in xml literals has proven to be a disaster
15:39:29 <ivan> q+
15:39:33 <ericP> pchampin: may it didn't work out 'cause it was the only one available
15:39:35 <PatH> Having a normative requirement to play fair rarely works out.
15:39:35 <AndyS> I agree requiring canonicalization has not worked out.
15:39:48 <ericP> +1 to pchampin's point
15:39:54 <pchampin> zakim, mute me
15:39:54 <Zakim> pchampin should now be muted
15:40:17 <Zakim> -AZ
15:40:21 <cygri> q+
15:40:35 <ericP> ivan: technically, two types could work, but i don't see the motivating use cases
15:40:52 <davidwood> ack ivan
15:40:57 <ericP> ... mostly i've seen e.g. excerpts of HTML in RSS, used only for display
15:41:09 <ericP> ... i don't think we should define another form of these datatypes
15:41:27 <pchampin> @ivan: fair enough :)
15:41:27 <ericP> ... anyone could add that type
15:41:31 <ericP> q?
15:41:36 <davidwood> ack cygri
15:41:40 <ericP> cygri: +1 to ivan
15:41:59 <ericP> ... it might be useful to keep the definition of the canonical mapping in the datatype
15:42:22 <ericP> ... XS datatypes optionally define canonical forms
15:42:55 <ericP> ... it's nice to indicate how c14n can be used by interested systems
15:43:11 <PatH> If caonicalized data smells the same as uncanonicalized, then nobody can rely on the canon, so its not worth doing the work to canonicalize it, so we have a huge negative feedback situation.
15:43:12 <ericP> ... there's no obligation, and for some systems it's useful
15:43:26 <ericP> ... i think that pointing to the c14n algorithm is a good idea
15:44:22 <ericP> ... also helps migration of RDF2004 to RDF1.1 by saying that the new lexical space encompasses the old space
15:44:55 <PatH> Maybe have a datatype for canonicalized data?  rdf:CXMLLIteral, to let people know what they are getting. 
15:46:10 <cygri> ericP, no, it doesn't mention unicode normalization
15:46:13 <ivan> PROPOSED: in RDF 1.1 (a) XMLLiterals are optional (b) lexical space consists of valid XML fragments © the canonical lexical form is c14n (d) the value space consists of DOM trees
15:46:35 <cygri> s/valid/well-formed/
15:46:48 <pfps> Q : is this harder than the current situation or easier?
15:47:13 <PatH> And for who? (publishers or consumers?)
15:47:17 <gavinc> Yes.
15:47:19 <pfps> easier is good!  :-)
15:47:25 <LeeF> I'm with pfps.
15:47:28 <zwu2> Are DOM trees unique?
15:47:42 <gavinc> Easier to publish and easier to consume
15:47:45 <Arnaud> zwu2: not necessarily
15:47:54 <PatH> I like that this doe not use the word "canonicalize"
15:47:57 <Arnaud> only after normalization
15:47:59 <zwu2> then, which one should we canonicalize into?
15:48:13 <MacTed> +1
15:48:17 <ericP> 1+
15:48:19 <AndyS> Looks best of (difficult) choices to me.
15:48:19 <ericP> q+
15:48:27 <ericP> ivan: i am much more interested in keeping publishing easier
15:48:33 <davidwood> ack ericp
15:48:44 <PatH> +1 ivan
15:48:45 <sandro> +1 ivan: we should make it easier for data publishers, even if it makes things harder for SPARQL implementers
15:48:52 <MacTed> (that is, +1 make publishing easier, even at the expense of making SPARQL/consumption harder)
15:49:03 <ivan> q+
15:49:04 <AndyS> q+ to address the SPARQL aspect
15:49:30 <gavinc> +q to point out that SPARQL stores can still use C14N
15:50:38 <davidwood> ack ivan
15:51:19 <ericP> ivan: in RDFa, the test harness uses SPARQL ASK to test a particular pattern
15:51:41 <gavinc> -q
15:51:44 <ericP> ... we had immense problems with the SPARQL literals, uneven implementation
15:51:57 <davidwood> ack AndyS
15:51:58 <Zakim> AndyS, you wanted to address the SPARQL aspect
15:51:59 <ericP> ... it's aleady a mess; we won't make it worse
15:52:21 <ivan> s/SPARQL literals/XML literals in SPARQL/
15:52:22 <ericP> AndyS: i think the SPARQL stores would handle it at load time instead of query time
15:52:42 <ericP> would entailment permit that?
15:53:27 <gavinc> You end up building hashes based on the DOM itself and the XPath/XQuery data model, see ;)
15:53:29 <davidwood> q?
15:53:33 <ericP> [ discussion of errors in large uploads ]
15:53:52 <davidwood> q?
15:54:20 <ivan> PROPOSED: in RDF 1.1 (a) XMLLiterals are optional (b) lexical space consists of valid XML fragments © the canonical lexical form is c14n (d) the value space consists of DOM trees
15:54:31 <zwu2> q+
15:54:46 <zwu2> zakim, unmute me
15:54:46 <Zakim> zwu2 should no longer be muted
15:54:49 <PatH> What does  ©  mean here?
15:54:56 <ericP> davidwood: i think no one objects to XMLLiteral are optional or lexical space consists of valid XML
15:54:57 <MacTed> PatH - client error
15:55:01 <gavinc> +1 to a, b, c, and +∞ to d
15:55:05 <pfps> \me (c)
15:55:11 <ivan> pat: my client turned ( c ) into a copyright character:-(
15:55:18 <AndyS> PROPOSED: in RDF 1.1 (a) XMLLiterals are optional (b) lexical space consists of valid XML fragments (c) the canonical lexical form is c14n (d) the value space consists of DOM trees
15:55:20 <PatH> AH. Duh.
15:55:28 <MacTed> PROPOSED: in RDF 1.1: [a] XMLLiterals are optional; [b] lexical space consists of valid XML fragments; [c] the canonical lexical form is c14n; [d] the value space consists of DOM trees.
15:55:30 <pfps> \me that's because it *knew* that you worked for W3C
15:55:41 <MacTed> *heh*
15:55:44 <ivan> q+
15:55:59 <davidwood> ack zwu
15:56:34 <PatH> I wonder what is the point of stating that there is a canonical lexical form if peple arent obliged to use it and users can't tell if it has been used or not. 
15:56:41 <ericP> zwu, i like the idea of c14n, but is c14n + serialization a unique process?
15:56:45 <MacTed> Zakim, who's noisy?
15:56:55 <ivan> q?
15:56:56 <Zakim> MacTed, listening for 10 seconds I heard sound from the following: Guus (15%), davidwood (29%), Ivan (55%), zwu2 (15%), ericP (35%)
15:57:10 <zwu2> I want to know if c14n + serialization a unique process
15:57:27 <zwu2> actually ericP captured my question, thanks!
15:57:46 <ivan> A.isEqualNode(B) dom3
15:57:56 <ericP> ivan: we don't care, 'cause what counts is the equality in the value space
15:58:32 <ericP> Arnaud: that equivalence is post-normalization
15:58:55 <ericP> ... e.g. creating a single text node from a series of text nodes
15:58:56 <davidwood> q?
15:58:57 <Zakim> -pchampin
15:59:01 <PatH> I take it that the only purpose of mentioning a canonical form is so that equality reduces to string identity (or close) . If this is not an issue, then lets just not even mention canonicalization. 
15:59:10 <ericP> cygri: not needed 'cause the DOM tree is the result of parsing
15:59:13 <davidwood> PatH, yes
15:59:30 <zwu2> +1 to PatH
15:59:37 <ivan> Pat that was my point...
15:59:37 <Zakim> -pfps
15:59:51 <PatH> Ivan, then delete ( c )
16:00:09 <ericP> Arnaud: that's not defined
16:00:24 <ericP> ericP: i've seen the opposite from MSXML3
16:00:44 <Zakim> +??P6
16:00:49 <ivan> q+
16:00:52 <pfps> zakim, ??p6 is me
16:00:52 <Zakim> +pfps; got it
16:00:55 <ericP> davidwood: we could have this same discussion based on, say, a style modification
16:00:58 <davidwood> ack ivan
16:01:10 <ericP> ... we can never solve this, just assympotically approach it
16:01:27 <PatH> Davidwood, Oooh yes, lets!
16:01:28 <gavinc> We can lean on DOM anyway here, or reuse the wording ;) "The childNodes NodeLists are equal. This is: they are both null, or they have the same length and contain equal nodes at the same index. Note that normalization can affect equality; to avoid this, nodes should be normalized before being compared."
16:01:34 <ericP> ivan: HTML5 spec is very clear about how a document is turned into a DOM
16:01:55 <pchampin> zakim, mute me
16:02:02 <Zakim> +pchampin
16:02:13 <Zakim> pchampin should now be muted
16:02:22 <ericP> ericP: does HTML5 produce exactly one DOM?
16:02:22 <gavinc> see
16:02:28 <ericP> ivan: assume so
16:02:59 <ericP> ... content to take Arnaud's advice about normalizing first
16:03:37 <davidwood> PROPOSED: in RDF 1.1: [a] XMLLiterals are optional; [b] lexical space consists of well-formed XML fragments; [c] the canonical lexical form is c14n; [d] the value space consists of DOM trees.
16:04:09 <cygri> [d] the value space consists of (normalized) DOM trees.
16:04:34 <davidwood> PROPOSED: in RDF 1.1: [a] XMLLiterals are optional; [b] lexical space consists of well-formed XML fragments; [c] the canonical lexical form is c14n; [d] the value space consists of (normalized) DOM trees.
16:04:38 <PatH> TO me, "canonical" is easy to read as meaning "recommended". Do we want to convey this?
16:04:56 <ericP> <root>abc</root> could be element(root, (text node(a),text node(b),text node(c)) or element(root, (text node(abc))
16:05:10 <AndyS> (XSD defines canonical forms -- does not force use)
16:05:24 <ivan> +1
16:05:27 <yvesr> +1
16:05:29 <Arnaud> +1
16:05:30 <cygri> +1
16:05:30 <MacTed> +1
16:05:32 <pfps> +epsilon
16:05:33 <ericP> +1
16:05:33 <gavinc> +1
16:05:33 <zwu2> -1 to [c] 
16:05:34 <PatH> -1
16:05:37 <davidwood> +1
16:05:42 <pchampin> +1
16:05:44 <sandro> +0
16:05:55 <PatH> that was -1 to [c], +1 to rest.
16:06:22 <pfps> Doesn't the current situation require canonicalization?
16:06:26 <gavinc> Yes.
16:06:37 <ivan> PROPOSED: in RDF 1.1: [a] XMLLiterals are optional; [b] lexical space consists of well-formed XML fragments;  [c] the value space consists of (normalized) DOM trees.
16:07:32 <cygri> ericP, why don't you ask them
16:07:35 <PatH> I am fine with canonicalization which is REQUIRED. BUt if its not required, we shouldnt mention it at all. 
16:07:43 <AndyS> -0.5 to not mentioning what the canonical form is : we are suggesting canonical for integers etc as good practice.
16:08:00 <PatH> Good practive is fine, but not in the definitions.
16:08:42 <AndyS> Jena checks - can't remember is it will canonicalize - maybe does it by string->DOM->string
16:08:43 <gavinc> PatH, ALL the xsd datatypes define a cononical form
16:08:44 <pfps> Does producing (normalized) DOM trees require canonicalization?
16:08:48 <gavinc>
16:08:53 <gavinc> pfps, no
16:09:22 <PatH> Gavin,. I know it is defined. The issue is, do we require its use in RDF data? If not, lets not mention it in the normative definition of the datatype. 
16:09:27 <AndyS> Non-normative section.
16:09:53 <gavinc> non-normative refrence to cononical form
16:10:00 <PatH> Exactly
16:10:00 <Arnaud> one difference between normalized dom and canonical xml for instance is that attributes are not ordered in the dom
16:10:10 <pfps> But, but, but, the RDF semantics requires that XSD-datatype RDF implementations map XSD literals into their real value, which is roughly equivalent to canonicalizing them, isn't it?
16:10:27 <gavinc> pfps, no, value space is not the same as cononical form
16:10:32 <ericP> AndyS: i'd be happy with the canonicalization in a non-normative section
16:10:34 <PatH> ? Where does it require that??
16:11:10 <cygri>
16:11:18 <cygri> this is already required in RDF 2004
16:11:18 <pfps> If you use a datatype, then the meaning of literals in that datatype is defined by the datatype mapping.
16:11:20 <ericP> zwu2: i'm happy if i can find a c14n which will work across triple stores
16:11:38 <ericP> ... if we apply that, would we get a unique serialization?
16:11:39 <PatH> BTE, I also like "cononical" which I think  means "made into the form of a cone"
16:11:50 <ericP> ivan: yep, was designed to support XML signature
16:12:07 <gavinc> Yes, provides a perfectly unique set of bytes for any equalivite XML 1.0 DOM
16:12:10 <ericP> davidwood: C14N is a REC and already required in RDF2004
16:12:57 <ericP> ... so we just have to make sure we don't change that ref to excl c14n
16:13:06 <davidwood> PROPOSED: in RDF 1.1: [a] XMLLiterals are optional; [b] lexical space consists of well-formed XML fragments; [c] the canonical lexical form is, as defined in RDF 2044; [d] the value space consists of (normalized) DOM trees.
16:13:33 <davidwood> PROPOSED: in RDF 1.1: [a] XMLLiterals are optional; [b] lexical space consists of well-formed XML fragments; [c] the canonical lexical form is, as defined in RDF 2004; [d] the value space consists of (normalized) DOM trees.
16:13:42 <ivan> +1
16:13:43 <MacTed> +1
16:13:43 <cygri> +1
16:13:44 <PatH> I still dont kow what [ c] means. Can I publish RDF data using this datatype that is not canonicalized?? 
16:13:44 <Arnaud> +1
16:13:45 <pchampin> +1
16:13:47 <ericP> +1
16:13:47 <zwu2> +1 thanks for the clarifications
16:13:50 <gavinc> PatH, yes.
16:13:52 <davidwood> +1
16:13:59 <AndyS> +
16:14:00 <PatH> Thern =1 from me. 
16:14:12 <gavinc> Just as you can write "01" or "1" or "000001"
16:14:15 <pfps> +2epsilon
16:14:19 <danbri> +1
16:14:20 <gavinc> +1
16:14:20 <sandro> +1
16:14:30 <zwu2> very good decoding still David
16:14:35 <zwu2> s/still/skill
16:15:03 <ivan> RESOLVED: in RDF 1.1: [a] XMLLiterals are optional; [b] lexical space consists of well-formed XML fragments; [c] the canonical lexical form is, as defined in RDF 2004; [d] the value space consists of (normalized) DOM trees.
16:15:07 <Arnaud> I have to go
16:15:13 <PatH> BUt readers of our spec will NOT read it as math. We just created a tutorial nightmare that will ast for decades. 
16:15:14 <Zakim> -Arnaud
16:15:16 <Zakim> -yvesr
16:15:16 <Zakim> -Sandro
16:15:17 <Zakim> -zwu2
16:15:17 <Zakim> -MacTed
16:15:18 <pchampin> bye
16:15:18 <Zakim> -danbri
16:15:20 <Zakim> -tbaker
16:15:21 <cygri> thanks all!
16:15:21 <Zakim> -Ivan
16:15:23 <Zakim> -pfps
16:15:27 <Zakim> -AndyS
16:15:34 <Zakim> -cygri
16:15:37 <Zakim> -gavinc
16:16:00 <cygri> ACTION: cygri to implement ISSUE-13 resolution in RDF Concepts
16:16:00 <trackbot> Created ACTION-169 - Implement ISSUE-13 resolution in RDF Concepts [on Richard Cyganiak - due 2012-05-16].
16:16:08 <PatH> Rather you tahn me, MacTed :-)
16:16:34 <Zakim> -ScottB
16:17:58 <Zakim> -pchampin
16:19:44 <Zakim> -LeeF
16:20:20 <Zakim> -Guus
16:21:29 <gavinc> gavinc has joined #rdf-wg