See also: IRC log
<DanC> I tweaked the agenda a bit; see http://www.w3.org/2001/sw/grddl-wg/weekly-agenda 1.49
<briansuda> Zakim [IPcaller] is briansuda
<DanC> RESOLVED: to accept http://www.w3.org/2006/10/04-grddl-wg-minutes as a true record
<DanC> RESOLVED: http://lists.w3.org/Archives/Public/public-grddl-wg/2006Oct/0023.html is a true record
<DanC> http://www.w3.org/2004/01/rdxh/spec#intro v 1.120 2006/10/18 06:01:56
<DanC> ACTION: DanC to flesh out ways to express author information in different markup languages [CONTINUES] [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action01]
<DanC> some progress
xhtml example removed to help text fit page better
iandd: has a stonger feeling that there should be an xhtml example
?? there are a lot of xhtml examples
iand: I can live with this - just wondering if other people had the same feeling
danc: I will think about it further
re ACTION:: iand to review Murray's suggested intro
the intro has been revised
iand: would like to continue action to review in new version within week
<scribe> ACTION:: iand to review Murray's suggested intro [CONTINUED] [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action02]
chime: some aspects of the intro (last edit) had a peice about Stephen King that I thought didn't make sense in a specifcation rather than a primer. What roles do the different documents play
danc: I'm thinking that the spec readers will find a brief explanation of RDF useful
murray: one of the goals of a common introduction is that previously the different intro's were trying to say the same thing but saying it differently
scribe: some of them drew value judgements about RDF that risked offending readers
chimezie: can you provide an example?
murray: they said RDF enabled automation -
but there's been automation for a while without RDF.
... tried to say the same
things in a more neutral way
... laying out the background for a problem space
... suggests value is common form across different xml
dialects
... experienced readers will skim intro, less experienced will
read intro
... intro has a guide to the other documents to aid readers
navigate the document set
... example removed last night after discussion with DanC
chimezie: is the aim not to repeat intro?
murray: my aim was to have a common intro - only slightly taylored for each one.
chimezie: seems to me like different docs need different intros
danc: in the primer I don't want background, I want it to tell me what to type
iand: should we explain the benefits of RDF in these documents
chimexie: I have issues with the explanation of RDF because it tries to add value to RDF.
DanC: do you want the paragraph struck?
chimezie: I would like one para struck
murray: if you take that out - it breaks the flow - need to remove the whole intro
chimezie: I don't agree
DanC: I disagree [with Chimezie]
Murray: do you think its harmful?
chimizie: my problem is that the text still tries to add value to RDF at the expense of other technologies
chimezie: I think the problem is that we don't have consensus on the purpose of each document
danc: we don't have to agree on that; we have to agree on the text
Murray: I have proposed a cross
set intro - but we haven't reached agreement on that
... the intro explains the bare minimum of what RDF is
about
... I tried to ensure that the bit about RDF was not
bragging
chimezie: I have more of a concern if the language is about RDF; my issue with the introductions is really to do with where they are in the documents; its not a strong objection
danc: if you get inspiration on how to change this pleas send mail
Danc: I removed references to
'meanings' and expressed things in terms of graphs - e.g.
merging graphs
... it was more straightforward to talk about graphs than
rdf/xml documents
chimezie: I originally had that opinion, but for interoperability reasons it is better to have one format
danc: interoperability is
important, but we can address the format issue elsewhere
... our test cases will be rdf/xml
chimezie: if you don't require it, then the processor has to cope
danc: I don't think this increases the implementation burden
iand: most implementations run xslt and then have to parse the results
scribe: the output of the xsl is a textual format usually rdf/xml - but it could be n3
danc: does that make sense to
you?
... the xslt process can set the output media type
chimezie: not all transforms can output a mime-type
danc: the spec requires the output is an rdf graph - which implies there must be a mime-type
murray: the transform may have a graph - then serialise it
danc: as opposed to passing the graph over with an api call - yeah
chimezie: there is a significant difference between outputing a graph and outputing a serialization of a graph which need thought through
<chimezie> the transformation algorithm for the most part is a syntactic transformation
iand: the user sees a graph; how does the processor know how to output the graph
danc: we'll show examples
iand: what is the most interoperable way to do it
danc: xslt 1.0 and rdf/xml
chimezie: if the spec talks about
graphs - it opens a can of worms
... if you require a specific syntax then there are fewer
worms
danc: the worms are there
whatever you do - if the spec says rdf/xml and you get
something else - the code still has to cope
... I suggest you try working it out because it was not
straightforward when I tried it
chimezie: if you allow multiple syntaxes then the code is more complex
murray: could we have a section on exposing the GRDDL results
chimezie: murray you previously argued for 1 in and 1 out to make it easier to support multiple syntaxes
murray: DanC's policy is to talk about what is in the spec
chimezie: what does a processor have to spit out?
murray: its your processor that is running - so you can write your code to assume what your processor does.
chimezie: it works for xslt but
not all transform languages can output a mime-type.
... if you have a transform which you refer to, say java
script
... which produces a concrete syntax
...
danc: what the spec requires is that the transform output a graph
chimezie: maybe I should formulate a test case and discuss later
murray: do we need a section on implementation guideance on output
danc: I think the market place will take care of this
<DanC> ACTION: DanC to add a sample implementation appendix to the GRDDL spec [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action03]
danc: we are planning to release
spec 24 Oct
... please support or abstain from that
ben: do you need that now
danc: I need an answer by the end fo the week
<DanC> ACTION: BenA to review grddl spec 1.120 by end of week [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action04]
Ben: ok I'll do that
<scribe> ACTION: chimezie develop test case to illustrate issues with output as graph rather than specific serialization. [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action05]
ian: would like to see released though have not fully reviewed
danc: the question is "how do we feel about releasing the grddl spec on 24 Oct"
rachel: sounds good but want to double check
<DanC> (critical path: BenA, RachaelY, ...)
brianS: I trust editor to make changes
<DanC> (critical path: BenA, RachaelY, Chime)
murray: authorize editor to take steps needed to get published and do not need to be in critical path
chimize: would like to be in critical path and am happy with deadline
<DanC> PROPOSED: to publish 24 Oct, contingent on editor (DanC) satisfying comments to come from BenA, Chime, Rachael
<DanC> PROPOSED: to publish 24 Oct http://www.w3.org/2004/01/rdxh/spec 1.120 + edits by DanC, contingent on editor (DanC) satisfying comments to come from BenA, Chime, Rachael
chime: will changes only be prompted by those on critical path
danc: there are changes I expect
to make, reviewing my @@ comments
... including fiture changes, citation cleanups,
murray: remove the log?
danc: sometimes I trim but leave it there
murray: awkward if you are printing
danc: not all @@'s will be addressed
seconded: chime
no objections or abstentions
so resolved
iand: I am working on primer document edits
<DanC> ACTION: Iand to address comments on primer [CONTINUES] [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action06]
iand: was held up by cvs access,
but that is now fixed
... will respond to comments as I do the edits
<DanC> ACTION: Brian and Harry to produce additional running code for the second part of the primer [CONTINUES] [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action07]
danc: brian - you and harry have action to write code - any news
brian: no progres yet
... do we need to respond to comments on the public list
iand: that's what I'll be doing
murray: what sort of comments
iand: some editorial, some on how vcalendar works
chime: was there a comment about an xml only example?
danc: there was a comment from Michael U? Shall I take that
<DanC> ACTION: DanC to respond to comment from Hausenblas, Michael http://lists.w3.org/Archives/Public/public-grddl-comments/2006OctDec/0005.html [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action08]
iand: yes please
chime: is there some way I can help with base param issue
danc: you are welcome to construct test cases
chime: if that's how I can help, that's what I'll do
<ryager> I've to run. Bye.
<scribe> ACTION: chime to help danc with test cases on base param issue. [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action09]
murray: is just for html documents
chime: also for xml documents
murray: does it go away if there is an explicit base
<DanC> ACTION: Danny to take testing test harness. [CONTINUES] [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action10]
chime: the issue what to do when it isn't clear what the base it - what do you do?
<DanC> ACTION: Murray to suggest what GRDDL spec issues are covered by XML Processing, suggestion on how to fix it. [CONTINUES] [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action11]
<DanC> ACTION:Iand to construct a content negotiation test case [CONTINUES] [recorded in http://www.w3.org/2006/10/18-grddl-wg-minutes.html#action12]
propose to adjourn
murray: seconded
<DanC> ADJOURN.