- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Mon, 09 Apr 2012 16:36:17 -0400
- To: ashok.malhotra@oracle.com
- CC: "www-tag@w3.org" <www-tag@w3.org>
On 4/9/2012 4:23 PM, ashok malhotra wrote: > Minutes from TAG f2f April 4 are available at: > http://www.w3.org/2001/tag/2012/04/04-minutes.html > and as text below: Thank you, Ashok. These are now linked from the combined agenda/minutes at [1]. Do you happen to remember who is doing the integration for Tuesday? Noah [1] http://www.w3.org/2001/tag/2012/04/02-agenda > > [1]W3C > > [1] http://www.w3.org/ > > - DRAFT - > > W3C TAG F2F 4 April 2012 (Sophia Antipolis) > > 09 Apr 2012 > > Attendees > > Present > Noah_Mendelsohn, Henry_Thompson, Jeni_Tennison, > Ashok_Malhotra, Tim_Berners-Lee, Jonathan_Rees, > Robin_Berjon, Larry_Masinter, Yves_Lafon, > Chris_Lilley_(for_the_morning) > > Regrets > Peter_Linss > > Chair > Henry, Noah > > Scribe > Noah Mendelsohn > > Contents > > * [2]Topics > 1. [3]httpRange-14 (continued) > 2. [4]Fragment Identifiers and Mime Types > 3. [5]Administrative - f2f dates > 4. [6]HTTP Range-14 > 5. [7]TAG Priorities > 6. [8]PhiloWeb > * [9]Summary of Action Items > __________________________________________________________ > > <noah> scribenick: noah > > <scribe> scribe: Noah Mendelsohn > > httpRange-14 (continued) > > JAR: We're continuing to follow my 7 section plan. Trying to > project consequences and criteria, interleaved. > > Shows whiteboard matrix of situations across top, solution > categories down left, and consequences in middle > > JAR: Talking about receiver, I.e. what Dave Orchard called > consumer -- someone trying to understand a URI, in context. > ... Three parties, sender sends a message to receiver within > which message is a URI. That URI is served by the linkee. > > HT: There are people who will buy in to what we propose (for > httpRange 14), people who bought into what we proposed 5 years, > ago, those who don't buy in > > TBL: Well, out there are people buying into a variety of means > of doing this > > <masinter> I don't understand this deconstruction of having > "bought in", since I don't see any records of transactions, > what it is they "bought into", who they bought it from, etc... > I can understand there are different constituents with > different opinions about what they do > > TBL: scribe missed some stuff... > > JAR: Want to restrict discussion to default rule -- i.e., no > special context in document around URI. > ... mostly we're filling in the white board.... > > LM: I'm confused. > > <masinter> Whether people will buy into a theory depends on > whether that theory is coherent to them and works for their use > case, among other things > > <masinter> Some reference to "OGP" > > <HT> OGP is a label for the use of hashless URIs for > non-documents > > <masinter> [10]http://ogp.me/ > > [10] http://ogp.me/ > > TBL: Roy says the server is an authority > ... scribe struggling to keep up... > > [11]http://www.w3.org/TR/webarch/#pr-uri-collision > > [11] http://www.w3.org/TR/webarch/#pr-uri-collision > > <ht> [Chris Lilley joins the meeting] > > <masinter> Theory: take "behavior when used in a@href" as the > definition of what a URI "means", derive all the other meanings > from that. img@src uses are similar but imply transclusion, and > xmlns. RDF use in A R B etc is then described in terms of the > a@href meaning. > > <jrees> See also JARs emacs buffer: > [12]http://lists.w3.org/Archives/Public/www-archive/2012Apr/001 > 8.html > > [12] http://lists.w3.org/Archives/Public/www-archive/2012Apr/0018.html > > <jrees> scribenick: jrees > > Fragment Identifiers and Mime Types > > reviewing draft product plan > > <noah> > [13]http://www.w3.org/2001/tag/products/fragids-2012-01-05.html > > [13] http://www.w3.org/2001/tag/products/fragids-2012-01-05.html > > NM: Look at whole space of fragids and mime types. Immediately, > concerns about 3023bis, about generic interpretation of fragids > ... one problem was that rdf+xml was operating in a manner > differing from rule proposed in 3023bis > ... we said, please abandon the generic rule > ... response was, the rule is important, we want to keep it > ... TAG said, OK, call out rdf+xml as a special case. > > <ht> > [14]http://lists.w3.org/Archives/Public/www-tag/2012Mar/0178.ht > ml > > [14] http://lists.w3.org/Archives/Public/www-tag/2012Mar/0178.html > > HT: action-675 was to prepare for this discussion. maybe no one > saw it > > action-675? > > <trackbot> ACTION-675 -- Henry Thompson to frame discussion of > semantics of fragids and rfc 3023bis -- due 2012-03-27 -- > CLOSED > > <trackbot> > [15]http://www.w3.org/2001/tag/group/track/actions/675 > > [15] http://www.w3.org/2001/tag/group/track/actions/675 > > HT: Jeni, a year ago, did this prep. This has to do with advice > for RDFa Core > ... we've done half of one part of her advice, we gave advice > to RDFa Core, they took it. > ... we never addressed the semantic conflict issue re RDFa > deployment, you retrieve HTML > ... Here are more detailed aims for now: Let's decide which > goals to tackle today > ... 1. Should advice in AWWW re. conneg and fragids - is it a > disagreement between media type registrations, or between > individual documents? > ... HT and JAR disagreed on this > > <ht> > [16]http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lil > ley-xml-04.html#frag > > [16] > http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag > > > HT: 2. What changes, if any would we like to see in 3023bis re > fragids? > ... (please ignore the expiration date, that's what we're > working with) > ... Are we still happy with our request to the editors? > ... JAR gave options, TAG said we prefer on balance option 2, > grandfather rdf+xml as a special case in 3023bis. One case > exception. > ... see reference 7 in ht's email > > <ht> > [17]http://lists.w3.org/Archives/Public/www-tag/2012Mar/0178.ht > ml > > [17] http://lists.w3.org/Archives/Public/www-tag/2012Mar/0178.html > > <ht> > [18]http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08- > 12 > > [18] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12 > > 3. What should we do with Jeni's draft finding? > > lm: The document defining media type regs is in last call in > app area WG > ... They added a vacuous SHOULD section about fragids. If we > want it to be stronger we need to make a comment by LC deadline > April 13 > ... Maybe Jeni's note provides input > > JT: We're not scoping discussion not just to RDF, but also > media fragment URIs (consult Yves), we found XML schema id > complications (consult HT) > ... would like to make sure these are part of the 3023bis > discussion > > <Zakim> jar, you wanted to talk about xhtml+xml > > JR: New information, I think xhtml+xml has the same issue as > rdf+xml, because of RDFa 1.0 > > <masinter> Proposal: create a separate internet draft on > "Fragment Identifiers for Media Type Registration", and ask > that the general media type registration document make > normative reference to it. > > NM: Can we do #2 first? > > CL: (Chris) When I agreed to rdf+xml exception, I thought that > was the only exception > ... Jeni section 2.2 points out other contradictions > ... SVG would need to change in order to allow media fragments > > <noah> > [19]http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08- > 12#inconsistent-semantics-and-processing > > [19] > http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12#inconsistent-semantics-and-processing > > > CL: Because SVG says syntax is either bare name or it's an > xpointer of some kind > ... this is true > ... because we expect to use [etc] > > <darobin> [20]http://simonstl.com/articles/cssFragID.html > > [20] http://simonstl.com/articles/cssFragID.html > > <ht> Jeni's document: > [21]http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08- > 12 > > [21] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12 > > CL: There is new CSS xpointer scheme that uses CSS selectors to > address frags within document > > <darobin> [22]http://www.w3.org/community/cssselfrags/ > > [22] http://www.w3.org/community/cssselfrags/ > > CL: community group > > YL: Design was to avoid any conflict with SVG for example, > > CL: Fine, but the SVG spec does not allow the new syntax > > YL: SVG with a viewport, identify a region. It's about the > scope of resolution of the fragment. Also based on application > > HT: We're currently stuck with 3986 which says determined by > media type > > JAR: No, it only says 'depends on' > > HT: We've always assumed that 'depends on' means 'defined by' > ... we've assumed fragid is discoverable from media type reg > (maybe by normative ref) > > <masinter> RFC 3986 " The semantics of a fragment identifier > are defined by the set of representations that might result > from a retrieval action on the primary resource. " > > HT: The SVG media type defines fragids, doesn't say anything > about media fragments > > CL: Surprise that the TAG has read it this way, not sure that > this is a valuable direction > > <masinter> "The fragment's format and resolution is therefore > dependent on the media type [RFC2046] of a potentially > retrieved representation, even though such a retrieval is only > performed if the URI is dereferenced. If no such representation > exists, then the semantics of the fragment are considered > unknown and are effectively unconstrained. Fragment identifier > semantics are independent of the URI scheme and thus cannot be > redefined by scheme > > <masinter> specifications." > > <masinter> we could update 3986 if we think that's wrong > > YL: SVG is a good example. image/svg+xml: there's a definition > in SVG, plus the +xml convention, plus the image/ (media > fragments) > > CL: multiple inheritance > > <masinter> I think the only resolution for media fragments > would be to *allow* media tpye registrations to point to it, > rather than *define* it to apply > > <noah> Best Practice 3: Fragment Identifiers in Media Type > Definition > > CL: Therefore carrying on with Jeni's doc. Best practice 3. > > <noah> Media type definitions should avoid 'must' language when > describing supported fragment identifiers as in practice it is > likely to be ignored. Instead, they should provide pointers to > any known fragment structures that might be applied to that > media type and give warnings of any contradictions between > them. > > YL: Also, there might be Javascript in SVG, and maybe RDFa > > <masinter> media type registrations should explicitly reference > everything they inherit > > YL: Someone might interpret it in JS, and make something out of > it > > <timbl_> The TAG ought to encourage generic processing of media > types to allow conneg to allow any form of migration between > languages and hence evolution of languages. So generic for > image/*, for RDFy things, etc. ... so we should not restrict > the fragment id spec to be only the media type spec. I wonder > in fact whether we should have a generic ruling that a localid > with no other puctuation be pointed out that it could be RDFa > or equivalent for any media type > > CL: SVG shouldn't try to give an exhaustive list > ... Lots of things need to be excluded, not just rdf+xml > > TBL: I might have jumped to assume that the media type spec is > the place to look, but generic media type semantics is > important, for evolution of the web > ... media fragments are important > ... in any XML language, if there's a short name without > punctuation, might be good to look for RDFa; then generic > warning at top fragid level, > ... if you have a language that allows barenames in host > language, you should make sure that you don't use same id in > rdfa to talk about something different > ... we should encourage generic > > <masinter> two paths: leave 3986's definition alone, or update > 3986. If you leave 3986 alone, you need to (a) require new > registrations to follow generic methods, and (b) update all > existing registrations > > CL: RDF ids are not XML ids > ... You're saying the two sets should not overlap > > TBL: One bag has punctuation, the other doesn't > > <masinter> I think leaving 3986 alone is workable, and updating > it is painful. > > TBL: Barenames should never be in the string set you define > > YL: You should avoid syntactical conflicts when you define a > new feature > > TBL: Stay away from bare names in particular > > <masinter> +xml, +exi, +json, +zip .... > > (JR notes RDF says nothing special about barenames) > > TBL: The simple syntax is sufficiently distinct to suggest > special treatment in 3023bis > > <masinter> There are some proposals to make scheme-specific > fragments for streaming protoocols of time-sensitive material, > e.g., "second 5-10 of rtp:<blah>" > > TBL: Otherwise, it's the local id idea, a huge flexibility > point, e.g. if you define a python media type, maybe the fragid > would refer to identifiers defined in the python content > > <masinter> Scripting language inheritance of fragment > identifies is another generic fragment identifier method > > TBL: You should be able to make global ids using language > native mode > ... When you're using barenames be careful since they'll be > used in this way. Be aware people inserting RDFa, and using > barenames, and people using barenames in host language must be > aware that they're sharing a single document-wide namespace, > and avoid using the same barename for two different things > > <masinter> I think "bare names" needs to fall out of the > collision avoidance for generic fragment identifier schemes > > HT: Some people not clear on what TBL said... here's an example > from the wild > > <noah> I heard Tim say: If you're defining a>framework< for > generating families of fragment IDs, e.g. XPointer, that > framework should not use barenames, leaving them for > non-framework use > > <timbl_> Yes > > (JAR has heard the directly contradicting opinion) > > HT: TBL, please see screen. An HTML doc with RDFa, primary > topic is #jack, with info about that, it's clear #jack is meant > by author to identify a person. And he's also put div > id="jack". Is this OK or is it bad? > > TBL: My preferred answer: bad. I want to link to one or the > other, in the same kind of context, to different kinds of > things. The 2 things have different properties > ... I want to be able to use RDF to talk about the DIV element > > <JeniT> Funnily enough, people who create these pages really > want a link that includes the #jack to jump to the appropriate > point in the document > > <ChrisL> So best practice, the set of (xml) IDs and the set of > (RDF) IDS on a given resource should be disjoint > > HT: In the example, the author might say the DIV is about Jack, > so what's the problem? > > <masinter> Generic fragment identifier mechanisms: +xml, rdf, > image media fragments, xhtml, javascript > > HT: Stipulate TBL's position, which one ought to be changed? > > <JeniT> So people have to create Javascript to interpret the > fragment identifier that is being used as the identifier for > the resource and map that into an anchor within the HTML > document > > TBL: Jack1 and jack2, separate fragids > > <timbl_> Meanwhile, for barenames, be aware that things like > RDFA will use barenames and so in other langauges or mixins > which use barenames, they share a document-wide space > > <masinter> I think what RDFa uses depends on httpRange-14 > > NM: I thought I heard CL say, that he has heard the TAG tell > this story, but if you want to understand fragid semantics, > then the pertinent spec is the media type registration > ... Noah wonders if Chris is suggesting loosening this. > > CL: Having looked there then you're not necessarily done. > > NM: Pushing back. IMO, the FYN story is quite important > ... specs should all point to each other > ... CL, are you suggesting otherwise? > > LM: The scheme plays NO part > > CL: Yes, there is FYN, 3023bis points to registry, which points > to registration. > > <darobin> [23]http://www.w3.org/2005/04/xpointer-schemes/ > > [23] http://www.w3.org/2005/04/xpointer-schemes/ > > CL: rec points to xpointer spec, which points to the xpointer > scheme registry > > <masinter> I was speaking in reaction to Noah's story in which > mentioned RFC 2616 > > SVG points to the +xml RFC, that gets 3023bis into play > > HT: 3rd thing, it acknowledges it's an image, so it points to > image/, CL says it doesn't need to point to media fragments > > CL: Need to update image/ spec to point to media fragments > ... that should do it > > NM: All pertinent specs should have such chains... > ... Register image/ at generic level, so that semantics can be > inherited from image/ > ... Principle is that there should be no contradictions among > the specs > ... you can't allow the last in chain to make contradictions > ... We may want to an equivalent thing in +xml, say that if > you're registering an xml type, there should be no conflict > > <Zakim> masinter, you wanted to propose a solution > > AM: We've been working with a few media types, there are rules > between them, they're connected > ... There is this cloud business too, there are tons of media > types. Cloud providers, machine, network, all media types > ... Lots of specs need to specify a particular special use of > fragids. They do so in media types, and sometimes that breaks > generic processing > ... All the cloud things use XML, without +xml in the media > type name > ... Suppose I want to specify a special semantics for fragids. > I can make my own media type, but I use XML, but no generic > processing > > <masinter> "Multiview": using multiple media types for the same > content, to get different interpretations (including fragment > identifier) > > NM: Generic processing is supposed to not conflict... there's > nothing in cloud+xml where 3023bis doesn't say you can't > [scribe missed] > > JR: Are they not using +xml because they don't want generic, or > because they're not aware, or they would like to, or what? > > AM: Checking > > <Zakim> masinter, you wanted to propose a solution > > LM: I typed what I wanted to say into IRC... there are 2 > solutions, we either keep 3986, or fix it. If we keep it, it > says meaning comes from media type rec [and consequent FYN > chain] > ... see 3986 > ... Semantics is defined by media type. Therefore it depends > > <noah> [24]http://www.ietf.org/rfc/rfc3986.txt > > [24] http://www.ietf.org/rfc/rfc3986.txt > > LM: That gets pointer to media type rec > > <noah> Quoting from the spec: > > <noah> "The semantics of a fragment identifier are defined by > the set of > > <noah> representations that might result from a retrieval > action on the > > <noah> primary resource. The fragment's format and resolution > is therefore > > <noah> dependent on the media type [RFC2046] of a potentially > retrieved > > <noah> representation, even though such a retrieval is only > performed if the > > <noah> URI is dereferenced. If no such representation exists, > then the > > <noah> semantics of the fragment are considered unknown and are > effectively > > <noah> unconstrained. " > > LM: Now we have javascript, xml, media frags, rdfa. > > <ChrisL> the "the set of > > <ChrisL> representations that might result" is not known to the > person using the fragment, so that is bogus for a start > > LM: Some of the real time folks have suggested fragids whose > semantics come from the scheme, because there is no retrieval > body > ... How do we reconcile these multiple source? One way, is that > you constrain all future registrations, and update the existing > ones. > ... Media type reg should mention that because you're +xml, it > should do xml thing, if it says it's an image type then ..., > > YL: You can't say this for future things? > ... I think it's good if the registration does best effort. > > LM: Can just inherit > > NM: HTML spec could allow for a registry > > LM: My point is either update 3986 to point to a different > source of generic inheritance other than media type reg, or you > change media type reg procedure to say that reg should point to > sources of semantics > > <noah> +1, especially to option #2 > > LM: A template could say scripts gets first shot, XML gets a > shot, +json, +exi, +zip, ... > ... There's an I-D saying every +xml automatically gets a +exi > ... We do have a use pattern to consider, the same document > could be served with different media types because you want > different processing, maybe because you want different fragid > processing > > <darobin> > [25]http://tools.ietf.org/html/draft-shelby-exi-registration-01 > > [25] http://tools.ietf.org/html/draft-shelby-exi-registration-01 > > LM: e.g. /svg vs. /svg+xml, or /xml vs. /rdf+xml, maybe media > type distinguishes processing in general, including fragid > semantics > > YL: One problem statement, we looked at it mainly from document > point of view. Look at doc in multiple ways. > ... Different problem is compound documents, i.e. a doc > containing multiple language, e.g. RDFa > > <masinter> > [26]http://tools.ietf.org/id/draft-shelby-exi-registration-01.h > tml > > [26] http://tools.ietf.org/id/draft-shelby-exi-registration-01.html > > YL: The consumer often knows what's intended. E.g. an RDF tool > that see HTML+RDFa, could present conflict to user. Issue in > 3023bis, you are applying generic processing in particular > instances , first problem space > > CL: If you start pointing to these, it's not going to work . > Classic example of compound doc without generic rules, is XSLT, > frags are not intended to be processed .... > > HT: If you use generic rules for XSLT, they work just fine. > What doesn't apply is semantics of embedded material, but no > one ever said that would work > ... XSLT doesn't require that XSLT style sheets be valid > ... validity not well-formed > ... The fragid #foo has a defined meaning, xpointer definition > says barename refers to first id= element > > TBL: That's a weasel. Consider spirit > ... The other fragids are there because they're quoted, I > support what CL says. It's not broken because of one-id > requirement > > <Zakim> ht, you wanted to suggest we're being pushed back > towards application-specific interpretations being allowed and > to project > view-source:[27]http://examples.tobyinkster.co.uk/hcard > > [27] http://examples.tobyinkster.co.uk/hcard > > <JeniT> Yves, what about the YouTube fragid into video example > you were talking about yesterday? > > <masinter> from > [28]http://tools.ietf.org/html/draft-ietf-appsawg-media-type-re > gs-04 > > [28] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04 > > <masinter> Since this was published, the defacto practice has > arisen for using > > <masinter> this suffix convention for other well-known > structuring syntaxes. In > > <masinter> particular, media types have been registered with > suffixes such as > > <masinter> "+der", "+fastinfoset" and "+json". This > specification formalizes > > <masinter> this practice and sets up a registry for structured > type name > > <masinter> suffixes. > > HT: We haven't done the first half. Where does this leave us > w.r.t. the +xml section of 3023bis. I'd be happy with: don't > use the same barename in your RDFa and in your XML, in a +xml > document. Unless you actually intend for them to have the same > denotation > > TBL: Do do it if they're the same > > <masinter> But it doesn't say anything about inheriting a > common definition of fragment identifier syntax > > <masinter> The primary guideline for whether a structured type > name suffix > > <masinter> should be registerable is that it be described by a > readily-available > > <masinter> description, preferably within a document published > by an established > > <masinter> standards organization, and for which there's a > reference that can be > > <masinter> used in a References section of an RFC. > > HT: A +xml that uses about="banana" as well as id="apply" is > OK, even though at the type level, the two are different. > ... What if the page had had jack1 and jack2, jack1 identifies > an element, jack2 identifies a person, I'm happy with that > ... That means there's no grandfathering required then > ... As Chris said, neither rdf+xml nor RDFa introduce XML > anchors in any way. Neither has any id= attribute > > <JeniT> There's no *technical* problem; of course the fact that > barename fragments are used with two separate semantics makes > it terribly confusing and impractical for people > > HT: So there is no problem with any XML generic processsor as > every id= that it finds as identifying the element. RDFa never > introduces id= > > NM: It now essentially says now and only, +xml owns the fragid > namespace. It could say, we own the ones that are defined, but > not the ones that aren't > ... Use syntax disjoint with xpointer if resolution will never > resolve to an id. > > <masinter> But javascript, image/ might add > > <ht> My proposal for 3023bis wrt fragids: The semantics of > barename fragment identifiers is as follows: for those > barenames in a +xml document which are "identifiers of an > element" as defined in [XPointer Framework], a barename fragid > identifies the element [XPointer Framework] says is does. The > semantics of all other barename fragids are unconstrained by > this specification. > > <JeniT> ChrisL, to capture what you said: document should be > updated to reference latest version of SVG (ref?) and point to > different handling in SVG Tiny > > <ChrisL> svg 1.1 first edition > [29]http://www.w3.org/TR/2003/REC-SVG11-20030114/linking.html > > [29] http://www.w3.org/TR/2003/REC-SVG11-20030114/linking.html > > <ht> I was quoting w/o attribution from 3986 > > <ChrisL> svg 1.1 second edition > www.w3.org/TR/SVG11/linking.html substantially identical > > <ChrisL> svg 1.2 big rewrite plus more sensible barename that > is not an svg and not an svgview > [30]http://www.w3.org/TR/SVGTiny12/linking.html > > [30] http://www.w3.org/TR/SVGTiny12/linking.html > > TBL: We were talking about XML and xpointer. Software that > processes XML is going to use xpointers, whatever the mime type > reg says. So we shouldn't be distracted by that. > ... we could obsess and talk about XML URIs used in the > pipeline, and so on. But MarkLogic will do xpointer, let's not > be put off by it > > <masinter> Compound documents are a use case > > <masinter> HTML5 fragement identifier? > > TBL: We're getting into compound documents stuff. Maybe this > pattern will become dominant. Maybe everything gets thrown > into, say, HTML > > <masinter> PDF is a compound document format > > TBL: We want to refer to all kinds of things in the same > namespace, maybe we should worry about this, not conneg, which > is simpler > > <masinter> Active document fragments more important than > compound document format? > > AM: To clarify, are you (TBL) saying we should back off on > generic processing? > > TBL: No. We've just seen a conflict, need to be aware that many > more may come along > > <masinter> "Last Call" in APPSAWG isn't IETF Last Call, it's > working group Last Call. > > <Zakim> timbl_, you wanted to say that in fact Norm's code will > process xpointers whatever specs say, in effect the things > processed by xml processing pipelines are in away things which > > <Zakim> ChrisL, you wanted to complain about the set of > possible representations > > CL: Reading through URI spec, it says you have to take the > union of possible representations, which you have no way of > knowing. Nobody will ever know about special leap day > representations > > <masinter> "If you say incoherent things, people sometimes > won't understand you" > > HT: Elsewhere in 3986 it talks about responsible > administration. You should resolve all or none, and should > happen consistently > > <timbl> For example, Ashok, people have been talking about > putting turtle into script tags with a type=text/turtle > > NM: You weren't talking about conneg, but rather about time > variation? > > <Zakim> ht, you wanted to propose the above as a resolution to > what 3023bis should say > > HT: Varying representations. Varying along any dimension > ... The example I put up leads to the proposal I entered > ... (displaying, see above) > ... Semantics is as follows > > CL: While this is good, there is a tendency for people to read > this and say "this is bogus" > ... Does it need to call out that other specs can nail it down? > > HT: TBL said don't trespass on the barename space, we ack that > > <Zakim> Masinter, you wanted to push Chris to submit 3023bis > ASAP > > LM: I want to make sure there's the chain from IETF media type > reg doc to +xml and to doc on fragids. > ... Why not resubmit 3023bis as I-D? > > CL: Holdup. Current 3023bis deprecates text/xml because it has > to be treated as US-ASCII. The reason is because of HTTP and > email specs > > <masinter> Why not resubmit it now? > > CL: HTTPbis fixes that, email is fixing it > > <scribe> ... New 3023bis will have different authors. Will not > deprecate text/xml, will say it is same as application/xml... > that's why the I-D wasn't submitted. > > We're still working out sequence of change w.r.t. email > > LM: Just put a disclaimer, get it out before the 13th > ... Because media type rec doc needs to reference something, > deadline soon. > > CL: Acknowledged, I intend to publish I-D new 3023bis, new > authors, as a placeholder, in next couple of days > > LM: TAG can send note to app area wg, with pointer to Jeni's > document, saying ... > > NM: Doc status is, I wrote this and it hasn't been reviewed, > ... > ... We want app area to look at these two docs... does anyone > object to pointing to unreviewed document? > > LM: I reviewed it > > NM: OK, referencing JT's doc as is OK? > > HT: Not comfortable yet, want to look at it > > LM: Can we put it on phone conference for Tues the 12th > > HT: Don't try to rush this > > <Zakim> Noah, you wanted to talk about Henry's proposal > > HT: I'm happy for it to go out tomorrow, to dated copy with > what Noah signaled (refer to doc, but doc hasn't had TAG > review) > > LM: No, we agreed to analysis, but not to the doc's > recommendations > > NM: No objections were heard. But review is not over. > > JT: Could we have an action on someone to write the note? > > LM: I will draft note if JT will review it > > <masinter> You can fix this by *always* using the tools alias > when you need to contact the chairs or ADs of this or any > working group:<appsawg-chairs@tools.ietf.org> > <appsawg-ads@tools.ietf.org>. > > LM: IETF only recognized individual people, not groups. > > NM: It will be signed by someone on behalf of the group > ... If there's churn there's a problem > > LM: Maybe I will just send a note, saying the TAG has talked > about it, long discussion. My own note. > > HT: I see no reason not to communicate officially > > NM: Problem is will this happen in the next week... > ... I would be happy if additionally if we gave advice to those > writing specific media type regs. Want to tell people how to > write the specs to make sure everything fits together > > HT: Yes. Maybe go even further and say barename space is a > valuable space, as TBL says... > > TBL: Advice to document authors > > HT: Where does this advice go? > > TBL: Would like to put it in 3986 > > HT: 3986? 3023bis? Media type reg RFC? > ... 3986 > > <masinter> To: apps area working group > > <masinter> Subject: draft-ietf-appsawg-media... review > > <masinter> The W3C Technical Architecture Group has been > working on issues around conflicting sources of fragment > identifier semantics in URIs, following the definitions in RFC > 3986 through the media type definition. We believe that those > defining and registering media types (including ones that > follow generic rules such as 3023bis ) may need more explicit > advice than currently contained within draft-ietf-appsawg-..... > We're working on recording and defining best practice for media > type definition and fragment identifier semantics; > --jeni-draft- is a document currently in preparation; our > intent is to develop this so it can be normatively referenced. > > CL: Generally OK with HT's proposal, need to think it over, but > spirit seems OK > > <masinter> my goal was just to set the expectation that they > should look at Jeni's draft as explaining the situation > > HT: Proposal: The TAG should make the proposal I entered to the > 3023bis editors > > <noah> Let's copy it here.... > > HT: We had different advice earlier. New info leads to the > above proposal > > <JeniT> Larry, that looks great to me > > <masinter> "draft-ietf-appsawg-media-type-regs" is the name of > their document > > HT: Should we now say, consequent on today's discussion and > JT's doc, there are multiple players, 3023bis to be responsible > should be very narrow about what is reserved to generic > processing and leave the rest open > ... wrt barenames, it only talks about the ones defined in the > doc, wrt to others, ... xpointer says error, we say no, not an > error, the semantics is devolved to someone else > ... we let others with a say in the matter to say it > > NM: Needs update to xpointer? > > HT: No, it's fine for media type reg to short circuit fragid > semantics in xpointer spec > ... As far as 3023bis and generic processing there's no there > there > > CL: You've produced a level of ordering. If xpointer doesn't > deal with it, then go to next level. > > HT: 3023bis can say this in advance of any update to 3986 > > <masinter> Jeni, should we point specifically to Best Practice > 3 "Fragment Identifiers in Media Type Definitions" as something > we want consensus on? > > HT: I'm trying to help 3023bis get out the door so it helps XML > community > > LM: The document Chris is preparing, and needs IETF consensus, > which is community wide. Whatever we say is obviously still > subject to that > ... Who would the TAG comment be to? > > HT: The 3023bis editors > > (JAR notes one of them is in the room) > > Discussion of whether it matters how this is said > > CL: I'd like to point out that I started down this road because > the TAG came to me > > <JeniT> Larry, I think we should say something like that we > anticipate there being recommendations about requirements on > media type registrations, such as that in Best Practice 3? > > LM: We got here because some people wanted to assume that if > they saw +xml, then generic xpointer processing was > appropriate. > > <JeniT> Larry, or no, that we want to specifically discuss what > to recommend > > <masinter> Jeni, would you like to suggest a rewording? > > <noah> We got here because the then current draft of 3023 bis > said they MUST treat as generic > > <masinter> When there are multiple communities who disagree on > best practice, it's hard to get consensus on recommending one > of their uses over the other. > > <ht> RESOLUTION, The TAG requests the 3023bis editors to adopt > the following wrt fragids: The semantics of barename fragment > identifiers is as follows: for those barenames in a +xml > document which are "identifiers of an element" as defined in > [XPointer Framework], a barename fragid identifies the element > [XPointer Framework] says is does. The semantics of all other > barename fragids are unconstrained by this specification. > Likewise wrt other fragids using registered XPointer schemes, > i.e. that XPointer "failure to find" errors are not errors, > rather a statement of unconstraint. > > <masinter> Can javascript eat up bare names before they get to > xpointer or xml? > > <masinter> ... and what about > [31]http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml- > authoring-guide.html > > [31] > http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html > > > JT: A bit concerned, this doesn't seem to give scope for > individual media type registrations to override > > HT: Calling it generic processing means there is no way to > override it for generic processing > > NM: I had proposed to go further > > JR: Can we propose that separately? > > HT: Consider MUST language in 3986 is separate > > LM: I don't understand the dependency > ... Does this bear on Polyglot? > ... If you have something that treats fragids as HTML > differently than xhtml+xml, could be trouble > > HT: If you access an xhtml, the fact that the xhtml spec says > something, is in scope. Indirection through xpointer spec > handles this > ... 3023 can't say anything about content not served with type > something+xml > > NM: text/html - HT answered this, when xpointer is used in > both, [3986 covers this case] > ... The explanation is tortured > > <darobin> [you can't tell if it's XML or HTML while it's still > in the box, but the cat is dead all the same] > > HT: Intent of xpointer authors [missed] > ... Note that I added to make clear that we want something > parallel for something for (...) xpointers as well. That's in > the draft resolution > > <noah> RESOLUTION: The TAG requests the 3023bis editors to > adopt the following wrt fragids: The semantics of barename > fragment identifiers is as follows: for those barenames in a > +xml document which are "identifiers of an element" as defined > in [XPointer Framework], a barename fragid identifies the > element [XPointer Framework] says is does. The semantics of all > other barename fragids are unconstrained by this specification. > Likewise wrt other fragids using registered XPointer schemes, > i.e. that XPointer "failure to find" errors are not errors, > rather a statement of unconstraint. > > <noah> Passed without objection. > > <JeniT> Larry, the only thing I'd add is to say what we'd like > them to do as a consequence > > NM: This rule either must not define interpretations for > fragids already covered here, or must not provide conflicting > definitions. Should say new specs *may* do new non-conflicting > stuff > > HT: What you must not do is specify a use for strings that will > appear in documents that they will be determined to id elements > by xpointers, so they'll fall under this clause; you must not > set users up to fail > > (Discussion of Noah's proposal, how to word) > > <JeniT> Larry, something like that we would like to discuss how > best to point media type registration authors to > recommendations about the definition of fragment identifiers > and the possibility of their draft pointing out to a separate > document providing those recommendations? > > HT: TBL's proposal is for 3986. There's nothing wrong at the > spec level with what rdf+xml says, since the user can always do > the right thing. They're never obliged to do so > ... You must not oblige users to hang themselves - that's hard > to say or place. > > NM: Spirit is: You could write pathological RDFa, and that's > OK. > > HT: Maybe we can find an example > > NM: We thought that RDF had made a mistake. The reasoning has > been so subtle that it's had us talking in circles > > The reasons they didn't make a mistake we may have just > discovered > > It appeared that 3023bis that would have applied to rdf+xml. > Experts thought it was a bug then realized it wasn't. Therefore > I'm inclined to urge health warnings. > > HT: You mustn't design your XML language so that people can't > achieve necessary reference using any fragid scheme without > introducing a semantic conflict with a URI involving a fragid, > that they can't express in some other way > ... After the comma isn't needed > ... , with respect to generic proessing as per 3023bis > ... You're trying to avoid: I need to use ids to identify > components. So you must write an id. To id a component, you > have to put an id on a piece of XML. > ... to refer to the component you have to write foo#x. But > generic XML says, if there's an id, then it ids an element. The > spec shouldn't ever put anyone in that position > ... that's what we're trying to warn against > > JT: It's OK if it's not typed as an XML id, yes? > > HT: Will the xpointer spec say that string ids an element? If > so, not good. > ... The one legit instance , the HTML spec says in English that > it's an anchor > ... Three ways xpointer says a string ids an element. schema, > xml:id, or if you know independently that it ids an element. > ... That's there so that you don't need the HTML DTD around > > NM: HT is not recommending exactly this text > ... I hear no objection to this direction > ... Not as urgent as the previous point. > > <ht> ACTION, Henry to work with Noah to draft a further request > to the editor from the TAG to include advice along the lines in > the discussion on media types and fragment identifiers at the > f2f on 2012-04-04 regarding what a particular +xml media type > registration should do wrt fragid semantics > > <ht> ACTION: Henry to work with Noah to draft a further request > to the 3023bis editor from the TAG to include advice along the > lines in the discussion on media types and fragment identifiers > at the f2f on 2012-04-04 - Due 2012-05-01 [recorded in > [32]http://www.w3.org/2001/tag/2012/04/04-minutes#action01] > > [32] http://www.w3.org/2001/tag/2012/04/04-minutes#action01 > > <trackbot> Created ACTION-688 - work with Noah to draft a > further request to the 3023bis editor from the TAG to include > advice along the lines in the discussion on media types and > fragment identifiers at the f2f on 2012-04-04 [on Henry > Thompson - due 2012-05-01]. > > <noah> ACTION-543? > > <trackbot> ACTION-543 -- Peter Linss to propose addition to > MIME/Web draft to discuss sem-web use of fragids not grounded > in media type -- due 2012-03-27 -- OPEN > > <trackbot> > [33]http://www.w3.org/2001/tag/group/track/actions/543 > > [33] http://www.w3.org/2001/tag/group/track/actions/543 > > <ht> ACTION: Henry to work with Noah to draft a further request > to the 3023bis editor from the TAG to include advice regarding > what a particular +xml media type registration should do wrt > fragid semantics along the lines in the discussion on media > types and fragment identifiers at the f2f on 2012-04-04 - Due > 2012-05-01 [recorded in > [34]http://www.w3.org/2001/tag/2012/04/04-minutes#action02] > > [34] http://www.w3.org/2001/tag/2012/04/04-minutes#action02 > > <trackbot> Created ACTION-689 - work with Noah to draft a > further request to the 3023bis editor from the TAG to include > advice regarding what a particular +xml media type registration > should do wrt fragid semantics along the lines in the > discussion on media types and fragment identifiers at the f2f > on 2012-04-04 [on Henry Thompson - due 2012-05-01]. > > <noah> ACTION: Jeni to sort next steps on Fragment Identifiers > and Mime Types - Due 2012-04-17 [recorded in > [35]http://www.w3.org/2001/tag/2012/04/04-minutes#action03] > > [35] http://www.w3.org/2001/tag/2012/04/04-minutes#action03 > > <trackbot> Created ACTION-690 - sort next steps on Fragment > Identifiers and Mime Types [on Jeni Tennison - due 2012-04-17]. > > Administrative - f2f dates > > Mon-Tue-Wed Oct 8-10 (or maybe 7-9) > > Pencil in Oct 7-10 > > NM: pencil in Oct 6 too pls > ... Drift is in England/France direction > > <timbl> The semantics of barename fragment identifiers in a > mimetype with +xml documentis as follows: When a format mixes > several languages, (as for example when we mix HTML, RDFa, SVG > and MathML), then each language allows things to be described > in terms of document-level bare names. Some of those may be > defined using the XML ID parameter, ans so will be processable > using XML pipeline tools. In this case, the barename fragid > identifies the element [XPointer Framework] says it does. The > semantics of all other barename fragids semantics of the > fragment are unconstrained by this specification. . > > <timbl> > [36]http://www.w3.org/wiki/HTTPURIUseCases#Refer_to_a_document_ > from_RDFa_within > > [36] > http://www.w3.org/wiki/HTTPURIUseCases#Refer_to_a_document_from_RDFa_within > > HTTP Range-14 > > <Ashok> scribenick: Ashok > > HT: JAR proposed we should start with the nuclear option > ... and discuss what the TAG would recommend to various > constituencies > > Jeni: What's the nuclear option? > > Noah: We need to discuss the change options that people have > proposed > > Jeni: We should decide the next steps > > JAR: Consequences of solution categories, criteria for choosing > a solution category, usecases for elucidating consequences > ... The advice that would be most difficult for folks to > swallow is retraction of HTTP Range-14 > > <masinter> Some people hate httpRange-14 and some people like > it. If you withdraw it, you make the people hate it happy and > the ones who like it unhappy > > <masinter> no? > > JAR: One criterion is interoperability among usecases > > Tim: Usecases are in different shapes > > <masinter> I'm concerned about sender and receiver > communicating, and I don't care about whether the linkee is > happy > > <masinter> The sender gets to decide which linkee to invoke > > Two Usecases for hashless URIs ... Dublin Core and FOAF > > scribe: See > > <jrees> [37]http://www.w3.org/wiki/HTTPURIUseCases > > [37] http://www.w3.org/wiki/HTTPURIUseCases > > LM: Define constituents more carefully ... senders or receivers > o people building Dublin Core ontologies > > <masinter> if we make linkees unhappy, i don't care. if some > recievers are unhappy but could be made happier by senders > choosing some other linkee to link to, then it's up to the > sender > > <masinter> Melville didn't write any web pages, did he? > > <masinter> > [38]http://www.operationteafortwo.com/wp-content/uploads/2011/0 > 7/mickey-mouse-au-BAC.png dc:creator ?? > > [38] > http://www.operationteafortwo.com/wp-content/uploads/2011/07/mickey-mouse-au-BAC.png > > > HT: Melville is not creator of electronic artifact > > Discussion about Usecase A) > > HT: I see a contradiction > > <masinter> dc:creator has to disambiguate > > JAR clicks on gutenberg URI in the usecase > > <masinter> is [39]http://www.ietf.org/rfc/rfc5013.txt the > appropriate spec? > > [39] http://www.ietf.org/rfc/rfc5013.txt > > HT: I cannot tell if foaf:maker encodes author or producer > > JAR: Tore Erickson claims every example like this is encumbered > > HT: Better if we choose a home page > > JT: Choose a blog > > <masinter> [40]http://dublincore.org/documents/abstract-model/ > > [40] http://dublincore.org/documents/abstract-model/ > > <masinter> Is there a mapping to the Dublin Core abstract > model? > > JAR: It's a beautiful idea but no one uses it ... hard to tell > what the properties of the URI are > > HT: The first usecases should be href=" ..." > > JAR: I want to avoid usecases that do not involve RDF > > Example 2: > > <masinter> You can only avoid use cases that don't use RDF if > you're willing to scope the results to only apply to RDF > > JAR: We would need to know something about what was on the page > > <jrees> Contrast of 2 examples is not based on what's fetched > > LM: We need to look at how dc:title is defined > > <masinter> i'm looking at > [41]http://dublincore.org/documents/abstract-model/ > > [41] http://dublincore.org/documents/abstract-model/ > > LM: I am looking at Dublin Core abstract model > > HT: Says "we build on RDF" > ... and to Pat's semantics > > LM: Would this solution make them rewrite the Dublin Core > abstract model? > > <masinter> Jonathan also wanted to review impact on creative > commons > > JAR: Let's look at Opt-Out > > No negative consequences for sender or receiver > > <masinter> [42]http://wiki.creativecommons.org/CC_REL > > [42] http://wiki.creativecommons.org/CC_REL > > JAR: Opt-In applies only if there is RDFa in retrieved content > > <masinter> gives some markup that CC proposes... will they have > to change? > > JAR: none of the Opt-In proposals describe what the > representation is > > HT: We need more qualification with Opt-In > > JAR: Need to say something about the content > > Discussion of improved Example 1 > > JAR: Default rule is what is used when there is no other > information about sender or receiver > > HT: Let us suspend attempt to fill in one more box ... > > How are we going to take this forward to create a > recommendation and convince people we have followed due > process? > > JT: Need to show what world looks for each example for each > proposal > > JAR: We said we would interact with community for 2 weeks > > HT: Need more than another 10 days > > JAR: I would like to ask for some revisions > > HT: We should rewrite in an understandable format ... then > involve others > > JAR: We should look at second usecase > > LM: I suggest we not spend a lot more time on this ... instead > form task force of concerned individuals > > NM: This is one of our top priorites ... cannot abandon it > > JT: Larry said "If we cannot drop it let's start a taskforce" > > LM: I don't remember being asked if this was a top-priority > ... but still should not absorb all of out attention ... we > have other priorities > > JAR: Task force to make us more effective? > > LM: Yes > > <masinter> RDFa / microdata is a priority > > <masinter> XML / HTML is a priority > > HT: We cannot do this until we have table filled in > ... getting others involved before that would be confusing > ... It will take a few person/days to fill out table > > <masinter> [43]http://www.w3.org/2001/tag/products/ > > [43] http://www.w3.org/2001/tag/products/ > > <masinter> I'd like to balance work on this vs. other > priorities > > JAR: We tried to form a taskforce and it failed ... we did not > have enough focus ... did not have the table filled in > > Tim: How about a taskforce selected from the TAG > > <masinter> based on the feedback I've gotten from observers of > the TAG, the priority vs. other topics should be adjusted > > Discussion of taskforce arrangements > > HT: Filling in table is not telcon time. > ... JAR will fill in table with whatever help he needs > > NM: We may need calls to review filled out table > > <masinter> Noah: JAR had first step, was second? > > <masinter> Noah: First step was to fill out the table > summarizing the functional characteristics of various solutions > > <jrees> 1. JAR with help fills out the table of categories X > use case X 3 roles. 2. *In parallel* we tell the community we > are doing so. Functional chars of different proposals. They > should look for that. 3. When JAR et al done, we will schedule > telcon. > > <masinter> Note that is plan > > JAR: Is this sufficient? > > <masinter> this is JAR getting help from other people > > <masinter> Jeni: happy to help > > <masinter> Ashok: do you want to set out a time frame? > > NM: Say 3 weeks? > > <jrees> ACTION jar to Prepare table as described in 2012-04-04 > minutes, for TAG review > > <masinter> /me > [44]https://www.w3.org/2001/tag/group/track/issues/63 > > [44] https://www.w3.org/2001/tag/group/track/issues/63 > > <trackbot> Created ACTION-691 - Prepare table as described in > 2012-04-04 minutes, for TAG review [on Jonathan Rees - due > 2012-04-11]. > > <noah> ACTION-282? > > <trackbot> ACTION-282 -- Jonathan Rees to draft a finding on > metadata architecture. -- due 2013-04-01 -- OPEN > > <trackbot> > [45]http://www.w3.org/2001/tag/group/track/actions/282 > > [45] http://www.w3.org/2001/tag/group/track/actions/282 > > <masinter> issue-63 has basis of draft: model, serialization, > vocabularies, linking. Think RDFa/microdata is part of metadata > architecture > > <masinter> issue-63? > > <trackbot> ISSUE-63 -- Metadata Architecture for the Web -- > open > > <trackbot> [46]http://www.w3.org/2001/tag/group/track/issues/63 > > [46] http://www.w3.org/2001/tag/group/track/issues/63 > > <masinter> product-5? > > Noah takes picture of Whiteboard with filled out matrix > > <masinter> > [47]http://www.w3.org/2001/tag/group/track/products/5 > > [47] http://www.w3.org/2001/tag/group/track/products/5 > > <jrees> ACTION-691? > > <trackbot> ACTION-691 -- Jonathan Rees to prepare table as > described in 2012-04-04 minutes, for TAG review -- due > 2012-04-24 -- OPEN > > <trackbot> > [48]http://www.w3.org/2001/tag/group/track/actions/691 > > [48] http://www.w3.org/2001/tag/group/track/actions/691 > > TAG Priorities > > <masinter> issue-50? > > <trackbot> ISSUE-50 -- URIs, URNs, "location independent" > naming systems and associated registries for naming on the Web > -- open > > <trackbot> [49]http://www.w3.org/2001/tag/group/track/issues/50 > > [49] http://www.w3.org/2001/tag/group/track/issues/50 > > JT: We said we would spend 10 minutes on Publishing and Linking > > <noah> > [50]http://www.w3.org/2001/tag/products/index-2012-02-16.html > > [50] http://www.w3.org/2001/tag/products/index-2012-02-16.html > > - Fragment Identifiers and MiME types > > LM: This is urgent > ... need credible schedule for completing our work in the next > few months > > NM: Jeni will update product page. Add Larry. > > HT: I can ask to be area reviewer for Ned's draft > ... or I can recuse myself > > - Publishing and Linking on the Web > > <masinter> on "Publishing and Linking" as a TAG product, we may > want to push it out of TAG into a CG > > <masinter> we publish a TAG note that suggests another body > take it up > > <masinter> i'm nervous about the plan for Publishing and > Linking > > <timbl> jrees, [51]http://www.w3.org/wiki/HTTPURIUseCaseMatrix > > [51] http://www.w3.org/wiki/HTTPURIUseCaseMatrix > > <masinter> there might be some discussion of scope of CG > > <masinter> initial draft asks feedback to TAG > > - URI Documentation Discovery > > JAR: Create an option for removing this work from the TAG > > <jrees> See also JARs emacs buffer: > [52]http://lists.w3.org/Archives/Public/www-archive/2012Apr/001 > 8.html > > [52] http://lists.w3.org/Archives/Public/www-archive/2012Apr/0018.html > > HT: Let's postpone that discussion > > Noah updates table online > > - MIME Architecture for the Web > > NM: Move this to a lower priority > > - Privacy by Design > > NM: Robin to draft product page > > - HTML/XML Unification > > <masinter> [53]http://c2.com/cgi/wiki?AlanKayQuotes: A new > point of view is worth 80 IQ points > > [53] http://c2.com/cgi/wiki?AlanKayQuotes: > > NM: Norm to visit TAG in June > > - Web Apps Storage > > NM: Robin to draft product page > > - HTML Data > > JT: Remove this > > NM: I owe you a closing note > > - XML/HTML Unification > > RB: Shall we shut down the taskforce? > ... no action lately > > NM: We still have outstanding issues for the TAG > > <masinter> should turn task force report into REC? > > NM: should we look at the issues. Tim said assign shepherd's > for the issues. > > JAR: I would like 10 minutes on this at the October f2f > > <noah> ACTION: Noah to consider JAR's april request to discuss, > for 10 mins, issues list at oct f2f - Due 2012-09-10 [recorded > in [54]http://www.w3.org/2001/tag/2012/04/04-minutes#action04] > > [54] http://www.w3.org/2001/tag/2012/04/04-minutes#action04 > > <trackbot> Created ACTION-692 - consider JAR's april request to > discuss, for 10 mins, issues list at oct f2f [on Noah > Mendelsohn - due 2012-09-10]. > > PhiloWeb > > LM: Henry, Tim and I are listed as talking for the TAG at > PhiloWeb > ... I was going to bring there my thoughts about Languages, > Implementaions and Versioning > > NM: Say it is your perspective > > ADJOURNED > > Summary of Action Items > > [NEW] ACTION: Henry to work with Noah to draft a further > request to the 3023bis editor from the TAG to include advice > along the lines in the discussion on media types and fragment > identifiers at the f2f on 2012-04-04 - Due 2012-05-01 [recorded > in [55]http://www.w3.org/2001/tag/2012/04/04-minutes#action01] > [NEW] ACTION: Henry to work with Noah to draft a further > request to the 3023bis editor from the TAG to include advice > regarding what a particular +xml media type registration should > do wrt fragid semantics along the lines in the discussion on > media types and fragment identifiers at the f2f on 2012-04-04 - > Due 2012-05-01 [recorded in > [56]http://www.w3.org/2001/tag/2012/04/04-minutes#action02] > [NEW] ACTION: Jeni to sort next steps on Fragment Identifiers > and Mime Types - Due 2012-04-17 [recorded in > [57]http://www.w3.org/2001/tag/2012/04/04-minutes#action03] > [NEW] ACTION: Noah to consider JAR's april request to discuss, > for 10 mins, issues list at oct f2f - Due 2012-09-10 [recorded > in [58]http://www.w3.org/2001/tag/2012/04/04-minutes#action04] > > [55] http://www.w3.org/2001/tag/2012/04/04-minutes#action01 > [56] http://www.w3.org/2001/tag/2012/04/04-minutes#action02 > [57] http://www.w3.org/2001/tag/2012/04/04-minutes#action03 > [58] http://www.w3.org/2001/tag/2012/04/04-minutes#action04 > > [End of minutes] > >
Received on Monday, 9 April 2012 20:36:48 UTC