<noah> scribenick: noah
<scribe> scribe: Noah Mendelsohn
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> http://ogp.me/
TBL: Roy says the server is an authority
... scribe struggling to keep up...
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: http://lists.w3.org/Archives/Public/www-archive/2012Apr/0018.html
<jrees> scribenick: jrees
reviewing draft product plan
<noah> 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> 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> 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> 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> http://lists.w3.org/Archives/Public/www-tag/2012Mar/0178.html
<ht> 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> 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> http://simonstl.com/articles/cssFragID.html
<ht> Jeni's document: 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> 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> 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> 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> 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> 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:http://examples.tobyinkster.co.uk/hcard
<JeniT> Yves, what about the YouTube fragid into video example you were talking about yesterday?
<masinter> from 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 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 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 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 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> 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 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 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].
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> http://www.w3.org/wiki/HTTPURIUseCases#Refer_to_a_document_from_RDFa_within
<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> 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> http://www.operationteafortwo.com/wp-content/uploads/2011/07/mickey-mouse-au-BAC.png dc:creator ??
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 http://www.ietf.org/rfc/rfc5013.txt the appropriate spec?
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> 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 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> 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> 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 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> 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> http://www.w3.org/2001/tag/group/track/issues/63
<masinter> product-5?
Noah takes picture of Whiteboard with filled out matrix
<masinter> 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> http://www.w3.org/2001/tag/group/track/actions/691
<masinter> issue-50?
<trackbot> ISSUE-50 -- URIs, URNs, "location independent" naming systems and associated registries for naming on the Web -- open
<trackbot> http://www.w3.org/2001/tag/group/track/issues/50
JT: We said we would spend 10 minutes on Publishing and Linking
<noah> 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, 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: 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> http://c2.com/cgi/wiki?AlanKayQuotes: A new point of view is worth 80 IQ points
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 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].
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
