- From: ashok malhotra <ashok.malhotra@oracle.com>
- Date: Mon, 09 Apr 2012 13:23:11 -0700
- 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