- From: ashok malhotra <ashok.malhotra@oracle.com>
- Date: Mon, 09 Apr 2012 14:03:53 -0700
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- CC: "www-tag@w3.org" <www-tag@w3.org>
Henry All the best, Ashok On 4/9/2012 1:36 PM, Noah Mendelsohn wrote: > > > 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 21:03:12 UTC