W3C home > Mailing lists > Public > www-tag@w3.org > April 2012

Minutes from TAG f2f April 4

From: ashok malhotra <ashok.malhotra@oracle.com>
Date: Mon, 09 Apr 2012 13:23:11 -0700
Message-ID: <4F83452F.3080804@oracle.com>
To: "www-tag@w3.org" <www-tag@w3.org>
Minutes from TAG f2f April 4 are available at: http://www.w3.org/2001/tag/2012/04/04-minutes.html
and as text below:

  [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]


-- 
All the best, Ashok
Received on Monday, 9 April 2012 20:22:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:14 UTC