Re: Minutes from TAG f2f April 4

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