Re: Minutes from TAG f2f April 4

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