See also: IRC log
NM: We'll start with some
factfinding
... More opportunities for strategy discussion later in the
agenda
... A brief look at our charter: http://www.w3.org/2004/10/27-tag-charter.html
[NM organised and recorded a round-the-table on measures of success for the TAG]
<DanC_lap> "What audiences should we address?" is the heading in Noah's emacs buffer that we're brainstorming in
<DanC_lap> yup; +1 video, mobile, web 2.0 (both the technical side, AJAX etc., and the social side: peer production)
<DanC_lap> http://esw.w3.org/topic/IetfW3cLiaison
<DanC_lap> (I note a vacancy in the W3C->OASIS liaison http://www.w3.org/2001/11/StdLiaison#OASIS )
<Stuart> FWIW: I think we (you) should continue with UniformAccessToMetaData; start taking a architectural perspective of WebApps (which takes in Conneg and #fragId) ie. develop conceptual model/vocab to speak about/identify client side entities; help find the balance point between distributed web language extensibility and mono-lithic centralise language dev;.
<DanC_lap> (note http://www.w3.org/2001/tag/em27 has various "foil sets" a la what Ashok suggested)
<DanC_lap> (the reason I've passed is that while there's lots of things I'd like to see, I have a hard time saying the TAG is the right place to do any of them.)
<johnk> why not say them anyway, for now, DanC?
<DanC_lap> because it raises expectations in a way that, as I say, I hesitate to do
<jar> (DanC, I conjecture that the TAG's docket my be populated by issues that fall through the cracks - that other WGs don't own - for better or worse)
<noah> This morning we did some fact finding as to what TAG members think might be success criteria, communities to be served, and specific work items for the TAG next year. We did not yet prioritize these, just list ones that anyone thought might be intersesting. The working list is checked in at http://www.w3.org/2001/tag/coordination/groupPriority.txt
http://www.w3.org/2001/tag/group/track/issues/60
<masinter> (conversation in break: http://larry.masinter.net/duri.xml )
NM: SW, do you intend to work further on ACTION-143?
SW: No sorry
trackbot, please close ACTION-143
<trackbot> ACTION-143 Review Raman's draft of webApplicationState-60 closed
<masinter> action-144?
<trackbot> ACTION-144 -- Noah Mendelsohn to attempt to articulate some of the higher level questions for inclusion in the draft. -- due 2009-03-03 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/144
trackbot, close ACTION-144
<trackbot> ACTION-144 Attempt to articulate some of the higher level questions for inclusion in the draft. closed
<jar> (JAR's explanation for posterity: ACTION-143 was on Stuart, who was asked to be left off the hook as he's no longer on the TAG. Consensus was that the action was not on a critical path and if a new action on someone else was needed we would issue it.)
NW: TVR, please introduce the issue
TVR: There's a draft finding, which
hasn't progressed much for the last 6 months
... the goal is not to find 'the correct answer'
... the work has been carried forward in an unstructured way by
Javascript hackers
... They use # to convey arguments to the script that runs on the
client in many 'modern' pages
... This is a big divergence on the face of it, because # was
supposed to be media-type specified
... But now text/html is often a program instead of/as well as a
document
<DanC_lap> (it might have been nice if a new media type had come along when HTML became turing-complete; maybe it's worth having a MIME type for HTML-with-no-javascript)
Draft finding: Usage Patterns For Client-Side URL parameters: http://www.w3.org/2001/tag/doc/hash-in-url-20080211.html
TVR: Because state is important to program-synthesised views, you need a way to reconstruct state from URIs
<masinter> application/postscript in early 90s was active content, program you downloaded. application/pdf has program parameters and has from pretty much the first plugin
<Zakim> DanC_lap, you wanted to ask to hear the rest of raman's question and to
TVR: You can put all your state in a
JSON dictionary, attach that dictionary to your URI with a #, and
then you can reconstruct your state on invocation
... So pulling on a URL doesn't get content, it gets you a program
which when run gives you the content
<DanC_lap> (well, I disagree that it doesn't give you the content; the program is the content; the output of the program is something else.)
<masinter> W3C Media Fragments working group is dealing with relationship to fragments too
TVR: The goal is, e.g. for a shopping
cart, to get the UI and DOM state to a known prior
configuration
... Consider a real-world example: playing a chess game
<masinter> Note that "bookmarking" is part of the web but not really clear part of webarch
TVR: We could reconstruct a board state by either recording the moves or by taking a picture of the board
<noah> Tim: certainly in the case of Google maps, the answer is yes, you can get links and email them. Whether they are implemented in quite the way Raman is describing, I don't remember (and can't check now because I am projecting)
<masinter> (might have something to do with relationship of state to search engines, too -- when do search give you a URL?)
TVR: The JSON + # story is the
latter, which avoids the potential downside of side-effects which
might come with the replay approach
... This approach also helps with Undo -- by keeping a stack of
JSON dictionaries, which you can pop to implement Undo
<Zakim> masinter, you wanted to talk about history of active content in MIME types, note architectural hole about relationship of # to MIME types in webarch
NM: We will need to come to the question of what we do about this, but let's go to the queue
LM: We did think of HTML for active content, for example application/postscript, as far back as the early 1990s
<DanC_lap> (I wonder when I read about "safe tcl" ...)
LM: There is an architectural gap: we
blythely gave the advice "what comes after the # depends on the
media type"
... but we left too much unspecified after that, as it were
<DanC_lap> (some data: Python Archives (1994q2): Fwd: twin interpreters in safe-tcl, but ...
<DanC_lap> )
LM: Media fragments, for example, are
struggling with this now, that is, pointing into the middle of a
video stream
... Or, application/pdf has a notion of parameters which can be
passed to the renderer. . .
... It would be good to look again at these architectural issues:
just what is it that we mean by media-type-dependent
semantics
... It occurs to me that bookmarking come up again and again in
this area, and we haven't said enough about that from the
architectural perspective
<DanC_lap> (what more would you expect in webarch re bookmarking? "There are substantial benefits to participating in the existing network of URIs, including linking, bookmarking, caching, and indexing by search engines, and there are substantial costs to creating a new identification system that has the same properties as URIs.")
TVR: and the Back button
LM: The progression of interactions between the user and the page results in a divergence between the URI you clicked and the one you need to reconstruct where you are
<DanC_lap> ("it's also under 3.4.1. Unsafe interactions and accountability, where "Although Nadia can print out the results, or save them to a file, she would also like to bookmark them.")
TBL: Sometimes it appears that I've bookmarked something, but it only works because there's a session ID in the background, which means they won't work later
TVR: Web apps have to manage state themselves, to make the Back button work
TBL: For multiple tabs, applications
have a more complex management problem
... I.e. If I'm tabbed out, and then tabbed back in again, here's
how I recover my state
<Zakim> timbl2, you wanted to mention the issue that video fragments needcommon media type
<Zakim> timbl, you wanted to ask whether in these apps typically one can bookmark these URIs and email them at all
TBL: I've been asked, wrt the TAG, that we have some consistent across all video formats way to use fragids to address by seconds or frames
<Stuart> Just dones some tag archaeology seraching for a mention of fragIds as "client-side indirection" from Roy... and have found an early life www-tag posting from him on the history of fragIds at: http://lists.w3.org/Archives/Public/www-tag/2002Jul/0253.html
TBL: and across all audio formats
<noah> Specifically, Tim is talking about vectoring only off the main (pre-slash) part of the mime type.
TBL: That is, this should be stated at the image/ or audio/ level, not at the level of individual media types
TVR: It would be useful to
standardise at that level, but in the absense of that, what people
are doing today is using text/html to ship a program, and # to ship
its arguments, and you can do anything you want
... For example, see the CNN video example in the draft
... So the challenge is that although we can come up with
content-type specific semantics of the #, but that's not how it's
being used today
<noah> Interesting... Martin Nally's case is similar in a way. With CNN, the # is on the URI for the container page, but the real (video) data has its own hidden URI.
TBL: Understood, but that doesn't change that we should encourage getting the high-level media type generic # interpretation for addressing into video and audio streams
<DanC_lap> (the video use case is 2.1 http://www.w3.org/2001/tag/doc/hash-in-url-20080211.html#id2261246 )
TBL: The fact that things are being hacked currently via text/html doesn't mean we can't get it right in the future
<masinter> the question is whether the current design patterns for using # to send parameteres to HTML with Javascript containers for video.... whether we could/should actually promote that to a recommendation
JK: The server makes a
representation, the client transforms it based on the #-passed
arguments
... So what the client produces may have nothing to do with the
original media type
LM: I think perhaps the program is a representation of the content
TVR: Well, how many arguments does a
postscript program take?
... PDF would be a better example
<Zakim> johnk, you wanted to wonder if the arch issue is that the final representation is not that sent by the server
<masinter> the resource / representation == consider a program which generates
JK: Is there an architectural issue, that what the user of a UA sees is not immediately well-described by the media type of the original GET response
HST: Yes
TVR: In principle a program is a representation of what it produces, but in practice that confuses people
<masinter> the ambiguity between "representation" and "program that generates the representation" is fundamental and irresolvable
<Zakim> noah, you wanted to talk about bookmarking and email
NM: Bookmark via email is particularly interesting for me, because it means the URI must be useable with no session context or other local App state storage
<masinter> a JPEG image is really a program written in the (impoverished) JPEG programming language which, when executed by a JPEG processor, produces an image on a screen or processor
NM: This connects up with Martin
Nally's use case
... There's a URI, with a fragid which in some way records the
state of a data resource
<masinter> turing complete is interesting but not relevant
NM: wrt the presenting UI
... You do eventually get down to resources and their
representations --it's not all javascript, the data comes in via
XMLHttpRequest and/or JSON fetches of some kind
<DanC_lap> hmm... I was drawing a kinda sharp line at turing completeness, but yeah, larry, I don't see any essential reason to, now that you put it that way, masinter
NM: There is typically a many-to-one
story here, with data from a number of sources
... in that respect Nally's use case is perhaps too simple, as in
his case there's only one subsidiary resource involved
<DanC_lap> (I find it awkward to refer to technical topics by people's names; looking up "Martin Nally's use case" ...)
NM: The bug itself is not enough to reconstruct the UI
TBL: The bug is an abstract thing
NM: No, it's a bug report, which is a document
<johnk> Martin Nally's email: http://lists.w3.org/Archives/Public/www-tag/2009Feb/0198.html
NM: If you conneg for RDF, I'll give
you the metadata in RDF
... The point is that in this case one of the data sources is
preferred
TVR: He could still have done multiple queries
<masinter> resources: angels, uris: pins
NM: In the mashup cases, you wouldn't be tempted to the kind of conneg approach Nally tries
<Zakim> DanC_lap, you wanted to follow up on bank web site builder audience
DC: It's good that the JS library
guys are showing good taste, and providing the wherewithall for
things to "work right"
... It's not good that banks still don't take advantage of that,
and so bank website usage is still often frustrating
<masinter> I think we should be careful to consider whether "they need a clear URI" questions are really "they need a good bookmark"
LM: I think the ambiguity between a program that generates a representation and a representation is fundamental
<jar> +1
LM: I don't think we can make a
useful distinction between 'active' and 'passive' content
... What's much more important is related matters of sandboxing,
access control, operational vocabulary, etc.
<Stuart> Hmmm... henry's writing on Web Proper Names spoke of a difference of what was transferred over the wire and what was presented to the user... but I forget the terms that he used.... Henry?
<ht>[representation and presentation][I think]
LM: Similarly, the parameters in fragments issue involves security questions
<johnk> "passive content", ie. HTML with fragid pointer into it could still be regarded as a program representation FWIW
LM: The requirements of a bookmark
are important to pin down
... This happens all the time with 'active content'
NM: A client-side 30x redirection
LM: When you look in the address bar,
they may not be happy with what they see
... If we include that the thing being displayed is a
representation, and that an important bit of metadata is "how to
get here again"
<Stuart> FWIW: Roy always referred to fragIds as providng "client-side indirection".
LM: and that the answer "what you used to get here" is just the default
TBL: The reason you don't put it in the address bar is that the browsers force a reload when you do that
<Stuart> see last 5 (short) paras of http://lists.w3.org/Archives/Public/www-tag/2002Jul/0253
TBL: for among other things security
reasons
... Thus the prevalence of the 'permalink' convention
... Maybe we should reconsider the redisplay requirement, to see if
that could be relaxed in favour of allowing the permalink to be
shown in the address bar
JAR: Email is still the litmus test
LM: Not sure, reproducability and longevity are not necessarily the same
<masinter> don't understand the email test, would appreciate an explanation
NM: What next steps do we commit to?
<masinter> "perma"link -- link needs to be repeatable and communicable, somewhat independent of its forever longevity
<johnk> I think Tim's statement about wanting the URL that appears in the browser address bar to be the "permalink" regardless of what is displayed in the browser is important
TVR: I walked away last year because there wasn't much interest or the necessary expertise in the TAG to take it further
<jar> (email is more demanding, but similar to bookmarking. what URI should get captured/sent/squirreled away, and what will be expected when it's used/received. bookmarking is transmission over time, email is transmission over space)
TVR: We could publish it 'as is' as a
Note
... but if we are going to take it forward, we'll need a commitment
to serious work to survey current usage more, and to articulate the
analysis to the point where we're confident that we've found any
conflicts that might be hidden
<masinter> I'm interested in pursuing the architectural issues we've raised, in a way that are relvant to HTML, Media Fragments, publishing this as a Note is fine as some background
NM: Who would be interested in taking this work forward?
AM: I found it very good when I read
it, but didn't get a direction from it
... That is, what is benign, what is dangerous
<masinter> permalink, relationship of fragments to media identification. this itself publish can be a background link
TVR: That wasn't my goal, yet -- facts first, evaluation later
AM: I think it's worth publishing in its current form
DC: I agree
<DanC_lap> (I understand better the concern that the TAG doesn't have the relevant expertise; indeed, I don't have a list of these patterns in my pocket, and I don't know specifically where to look.)
LM: I'm interested in pursuing the architectural issues raised here, particularly wrt the media fragments work already underway at W3C
<Stuart> Hmmm... I don't recall... but as a finding... what did it find - that people are making creative use of fragIds - i think that findings offer direction/advice.
<masinter> and publish this as a note with a preface that it is background
LM: I would like to see URL replaced by URI here
<masinter> because we are engaged in 'good speak'
<timbl> +1 s/URL/URI/g
<DanC_lap> (publish it as a "looking" rather than a "finding"? ;-)
HST: I heard support for publishing, but not as a finding
NM: We still need review before going
ahead
... I need volunteers to review this with an eye to publication
JK: I will
<masinter> i request that a note be added first identifying this as background material for the architectural issues we're going to address, and that we should raise those issues and reference the issues in the note
AM: I will
trackbot, status?
<scribe> ACTION: John to Review the current draft of Usage Patterns For Client-Side URL parameters for possible publication [recorded in http://www.w3.org/2001/tag/2009/03/04-minutes.html#action01]
<trackbot> Created ACTION-234 - Review the current draft of Usage Patterns For Client-Side URL parameters for possible publication [on John Kemp - due 2009-03-11].
<scribe> ACTION: Ashok to Review the current draft of Usage Patterns For Client-Side URL parameters for possible publication [recorded in http://www.w3.org/2001/tag/2009/03/04-minutes.html#action02]
<trackbot> Created ACTION-235 - Review the current draft of Usage Patterns For Client-Side URL parameters for possible publication [on Ashok Malhotra - due 2009-03-11].
<DanC_lap> (I take it as implicit that the status section will be updated as part of publication)
LM: I would like to see statement that this is background material
AM: I think that requires a lot more work
LM: I don't think so
NM: We'll discuss form and status subsequently
<DanC_lap> (wow... if I were one of the reviewers, I wouldn't be able to judge publication readiness without knowing the publication target status. but oh well.)
NM: We do need to decide what else we do on this issue as a whole -- this is an important area, and don't think this publication will be all we want to do
LM: I'm willing to compose a preface that will be attached to the publication
TVR: I'd like to publish this as a
Working Draft, without prejudice to how it eventually appears
... so that we have a heartbeat
<DanC_lap> +1 WD
HST: I think we would benefit from talking about the general issue of the relevance of the old-fashioned view of a web of documents with media types given the prevalence of synthesised content
<scribe> ACTION: Noah to Schedule discussion of the stress on media types imposed by client-side synthesised content [recorded in http://www.w3.org/2001/tag/2009/03/04-minutes.html#action03]
<trackbot> Created ACTION-236 - Schedule discussion of the stress on media types imposed by client-side synthesised content [on Noah Mendelsohn - due 2009-03-11].
NM: Adjourned for lunch
Noah: [reviews actions]
http://www.w3.org/2001/tag/group/track/issues/57
TBL: action-116 continues, remind me in a month
<DanC_lap> action-116 due 4 Apr
<trackbot> ACTION-116 Align the tabulator internal vocabulary with the vocabulary in the rules http://esw.w3.org/topic/AwwswDboothsRules, getting changes to either as needed. due date now 4 Apr
<masinter> Larry: what does this action have to do with the issue? It's not clear
[noah adds note to action 178]
<DanC_lap> action-178?
<trackbot> ACTION-178 -- Jonathan Rees to update draft of finding on uniform access to metadata. -- due 2009-02-13 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/178
<johnk> actions 178 and 200 seem to be almost identical
A decision is made to review JAR's draft.
<johnk> http://tools.ietf.org/html/draft-hammer-discovery-02
JAR: I probably need more info on what people want in order to edit my draft.
<masinter> not sure what this action is, what it's waiting for, etc.
http://www.w3.org/2001/tag/doc/more-uniform-access.html
[discussion of what that action was about, with tracker not giving a lot of clues]
JAR: That http://www.w3.org/2001/tag/doc/more-uniform-access.html is the doc I prepared for the November face-to-face. This is not the draft we are talking about
This http://www.w3.org/2001/tag/doc/uniform-access.html is the memo we are talking about which I promised to add a use case to.
<DanC_lap> action-178: jar says http://www.w3.org/2001/tag/doc/uniform-access.html is the doc to update
<trackbot> ACTION-178 update draft of finding on uniform access to metadata. notes added
Ashok: There is a 5 Feb 2009 version of that document (uniform-access) ... so isn't the action done?
JAR: Yes
<DanC_lap> close action-178
<trackbot> ACTION-178 update draft of finding on uniform access to metadata. closed
DanC: I want to talk about this substantively.
<DanC_lap> action-200?
<trackbot> ACTION-200 -- Jonathan Rees to revise "Uniform Access to Metadata" (needs title change) to add XRD use case -- due 2009-02-24 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/200
<DanC_lap> http://www.w3.org/2001/tag/doc/uniform-access-20090205.html#cross_site
DanC: Let's discuss this, with respect to ACTION-200
TBL: This is the most interesting case to me.
TBL: I am interested about steps 1-6 but not stage 7.
LM: We have chopped this metadata problem into the wrong chunks... we keep stumbling over all kinds of subproblem - trust, provenance, etc
<DanC_lap> This = "Cross-site communication of end user information" , which is related to current work on OpenID, OAuth, XRD, etc.
JAR: You need the roadmap I think. I
will present it.
... This is my roadmap for the issue.
... There is the redirections issue, which is about 30x
responses.
... we have gone though about 10 steps in this one particular
protocol -- the Description Resource Discovery Protocol. DRD
... This is a protocol. It does one particular thing.
... This is not uniform access, that is a different issue, which can
be uniform access to metadata, to information about things,
etc.
... The uniform access to information came about from discussions
of 303 responses.
<DanC_lap> issue-36?
<trackbot> ISSUE-36 -- Web site metadata improving on robots.txt, w3c/p3p and favicon etc. -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/issues/36
jar: the proposed protocol DRD
involve the link header, the link element and site metadata.
... The way that prople got to this protcol is really interestiung.
This is interesting from an appliations point of view.
... There are a bunch of people whose interests are now aligned,
and so this had momentum.
... The directions come from POWDER -- the first to bring it to the
TAG's attention --, and
... it comes from the OpenID and XRD technology.
... So this grows from the TAG's interaction with XRI --we wanted
to do XRI in a more web arch way.
... Eran was charged by OASIS to come up with a replacement protocol
to replace the conneg hack they were using.
... i got interested in this from the metadata point of view. People
don't want to change the GET behaviour but they do want to provide
metadata.
... there are a million ways to do it -- one has to pick one. That
is how I came at this from the metadata point of view.
... These people often can't edit the HTML pages to add link
elements for example.
... Things out of scope of this discussion are concepts of
authority, format and ontology/schema of the metadata.
... (Authority being in this case for example the authority
conferred upon a URI owner. We are not discussing the
authoritativeness of the metadata)
...
...
... this solves a way of setting a second communication channel,
the communication of metadata.
NM: We are sticking close to the scope of Issue-57.
JAR: Historically this came to our attention through POWDER.
<DanC_lap> (I was reluctant to add issue 57 in the 1st place; I hope I said so at the time.)
<DanC_lap> (I'd be happy to close issue 57 and replace it by issues much smaller than computer science and philosophy.)
<johnk> I'll just say this in IRC - the key to Eran's doc seems to be the describedBy relationship (ie. it's common to all that Tim wrote on the board)
<DanC_lap> (I didn't say so [i.e. don't open httpRedirections] at the time. oops. http://www.w3.org/2001/tag/2007/07/16-minutes#item06 )
<Zakim> timbl, you wanted to discuss the template versus powder as the main remaining issue in this area, happy with link header and link element and not sure about sitemeta as it is
<DanC_lap> (Dec discussion to which AM refers is recorded at http://www.w3.org/2001/tag/2008/12/10-minutes#item02 )
Tim: I think the issue is important. The Link header and link elements are important solutions. There are more issues with the hostmeta system. More roundtrips, syntax of hostmeta file, template system covers same ground as POWDER labels. And the way the spec is written is as an algorithm everyone must follow, but not on what the headers mean.
<johnk> Eran's draft mentions the 'describedBy' relationship, too, Tim - is that "what the headers mean"?
<masinter> I'm interested in the general question of metadata, formats, access methods, and authority, and I think the issues have been chopped up in a way that gets in the way of addressing the problems. You can't really talk about access to metadata without also establishing the range of formats and how you're going to indicate them, dealing with embedded metadata in formats for images (JPEG) video (closed captions) as well as HTML (RDFa)?
Ashok: there are these things described in the draft, have had two other possible mechanisms mentioned -- conneg, which we are not happy with --, and MGET, but it has a special data format. But MGET does not give you a set of URIs of metadata resources.
<masinter> putting a lot of effort into HTTP 303 redirection without having a roadmap of how it fits into the bigger picture will lead us into "ratholes": lots of effort looking at what might be the wrong problem
<DanC_lap> HT, would you type the problem description you gave a few minutes ago? it appealed to me but I don't see it in the log
Tim: Conneg cannot be used for this.
<ht> Problem description: A number of people have document collections with which they wish to associate metadata, without being able to edit the (HTML) content of the documents
<ht> They would like to appeal to a recognised standard which people can use to access their metadata
Ashok; What about MGET?
<masinter> We could close this issue to say "Using 303 is a bad idea, using CONNEG for this is a bad idea, and there are other mechanisms, but we're going to look at the big picture"
Tim: See appendix A
Masinter, we should recommend everyone use the same header so we get interop.
<masinter> http://tools.ietf.org/html/draft-hammer-discovery
<masinter> metadata doesn't fall from the sky: people make it, produce it, manage it, offer it, update it, disagree with it. The publication mechanism has to fit into the overall lifecycle of metadata, including accommodate the different ways in which sources of metadata have the authority and ability to control the mechanisms of dissemination.
[discussion of the bit about WebDAV OPTIONS and PROPFIND -- basically no one wants to do that level of upgrade to all their servers.
<DanC_lap> (maybe it was: $WHO has a bunch of web resources with URIs and some metadata about them and wants to help other parties find the metadata corresponding to them)
Tim: Also there is a big issue that MGET metadta does not have its own URI
Ashok: suggest we don't do anything until [something] happens.
<Zakim> noah, you wanted to talk about MGET
[discussion of scope]
<DanC_lap> (jar, the words you use to describe the problem make me sympathetic to LMM's concern)
JK: What is important is that the realtionship 'describedBy'.
JK: My idea of this issue is that we [...] [i]n this case does the describedBy relationship solve HTTP redirections?
<jar> (5-minute break)
Jar: i think LM is setting up a atrawman. The problem here is not metadata, it is access to metadata.
<DanC_lap> (metadata is in the image file sometimes, but not always)
Jar: You talked about metadata for
image and video, then often it is inside the file, so access to
metadata is not a problem. But access to metadata is what we need
here.
... If Eran and co. go ahead and implement and deploy this, what
risks may be involved?
NM: I want to discuss the description of the issue.
Tim: Clearly we have a problem in that LM does not approve of the use of 303 it seems, but we should not let that get in the way of resolving this issue.
<masinter> I don't think it's a strawman in the sense of a false target. and if this issue is scoped as "access to metadata for circumstances where there is no other access method, and where the format is well defined and the schema is agreed" etc. then i might be OK. But it says "access to metadata"
<DanC_lap> yes, masinter, that's a helpful refinement
<Zakim> ht, you wanted to say not either/or but both/and
HT: There is a problem for which these people are conveging on a solution. It is of interest to the TAG as it seems architecturally sound. I want to keep this issue open and watch and help it. Also we should open another broader discussion about the constelation of problems which Larry has talked about.
<trackbot> ISSUE-57 -- The use of HTTP Redirection -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/issues/57
<masinter> i'd still wonder whether this was high priority among all of the metadata problems facing the web, and whether metadata is a high priority compared to other TAG issues
<masinter> by 'this' I meant link headers, 303 responses, etc. as metadata access methods
<masinter> primarily because I htink it is very common for metadata publishers to be different from the data publisher, and methods that are only useful for the common authority won't be general useful
<DanC_lap> (indeed, we don't have a separate "uniform access to metadata" issue)
<DanC_lap> -1 broader issue
Poll: Informal 5 in favour of keeping open, 2 in favour of closing
<jar> Possible issue title: How does one discover description resources?
<DanC_lap> (I'd like noah to open an emacs buffer, put 2 thingies per tim's suggestion and paste larry's refinement above under one of them)
<masinter> i'm not suggesting having a "really broad" issue as much as reconsidering how they're chopped up
<masinter> 'discover' and 'publish' are two sides, and both need to be addressed
<DanC_lap> [2:31pm] masinter: i don't think it's a strawman in the sense of a false target. and if this issue is scoped as "access to metadata for circumstances where there is no other access method, and where the format is well defined and the schema is agreed" etc. then i might be OK. But it says "access to metadata"
<jar> How are description resources discovered and communicated?
<jar> ... that's too ambitious, too broad. Of course 3rd parties are often more reliable, but we need to hear from 2nd parties too, especially when we don't know about any 3rd party
"At their meeting in 16th July 2007 [1] the TAG resolved to create a new issue, HttpRedirections-57 as a response to a community request [2] that we give further consideration to the use of the HTTP 303 status codes for obtaining a description of a resource (typically a non-information resource) where the referenced resource is not capable of providing representations of itself."
<jar> If we parameterized by link relation (desrcibedby vs. etc.) that might help address format question
<jar> POWDER and OpenID might use different formats
Use of HTTP 303 from thing to data about thing
<masinter> where the mechanism for agreeing upon the metadata format is part of the solution and there is an interoperable mandatory to implement subset....
Uniform access to metadata
<masinter> and where there is some method for resolving the understanding of the meaning of the schemas for metadata
Given the URI of an HTTP-accessible information resource R, how can an agent learn the URIs of metadata documents about R?
<jar> strike the word 'information'
<jar> strike 'HTTP-accessible'
<masinter> of the metadata documents about R which are intended by the publisher of R"
<jar> s/strike 'HTTP-accessible'/ /
<jar> I still think 'information' can be stricken, but keep 'HTTP-accessible'
<jar> (I don't know what an 'information resource' is but I think I know what 'HTTP-accessible' means)
[discussion of splitting the issue]
<DanC_lap> 1st party metadata
<DanC_lap> (hmm... "from" or "endorsed by"?)
<noah> Issue 1:
<noah> Title: Use of HTTP 303 from thing to data about thing
<noah> Description:
<noah> The use of the HTTP 303 status codes for obtaining a description of a resource (typically a non-information resource) where the referenced resource is not capable of providing representations of itself.
<noah> Issue 2(Tim):
Discussing new split issue:
<noah> Title: Uniform access to metadata
<noah> Description:
<noah> Given the URI of an HTTP-accessible information resource R, how can an agent learn the URIs of metadata documents about R authorized by the owner of the original URI.
RESOLUTION: To split Issue-57 into two issues as edited by NM, with one abstension DanC
<noah> Propose new shortname uniformAccessToMetadata-XX
<DanC_lap> issue: uniformAccessToMetadata
<trackbot> Created ISSUE-62 - UniformAccessToMetadata ; please complete additional details at http://www.w3.org/2001/tag/group/track/issues/62/edit .
Askok: I will shepherd issue-62
<DanC_lap> action-227?
<trackbot> ACTION-227 -- Jonathan Rees to summarize TAG work on metadata, with Larry -- due 2009-02-24 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/227
http://www.w3.org/2001/tag/group/track/issues/34
HT: I am projecting this http://www.w3.org/DesignIssues/XML as a focus for discussion of questions of how you interpret in general XML documents, so that specs could quote a normal default way of interpreting XML documents.
For example I assume entities will have been replaced, xincludes will have happened, etc and so on .. and all x y and z for some set of x y and z.
this has taken Tim and me to the question of whether it is useful to think of the application semantics (?) of XML ... -- the vocabulary is tricky here --
HT: but you might find it useful
to distinguish between three layers of XML semantics.
1) The mimimal XML
semantics - XML 1.0 and NS.
2) The elaborated XML semantics which is the result of
doing all this stuff.
3) and there is application semantics, which is a
third layer.
HT: The documents which I have written about this are
the earlier one (2007-11-27)
"The elaborated infoset: a proposal"
scribe:HT: We don't want to freeze this
set of x y and z.
... So the elaborated infoset .
... Current caes are the XML stylesheet PI, the author's intent to
convey additional meaning, the readers licence to interpret hte
document as having it;
... There are elements in xinclude, and decryption.
Tim: Actually the stylesheet document duality thing was what has nested XSLT function elaboration
HT: All these things signal
elaboration.
... But Tim wasn't happy because of the probelm of quoting.
... The information content of an XML document should be
compositional in the traditional sens eof recursive specification
of the element in terms of the meaning of its children.
... but quoting gets in the way -- it is up to each vocab to tell
you which elements are quoting and block the recursive elaboration
of XML.
<johnk> noting that HT is now showing http://www.w3.org/2001/tag/doc/elabInfoset-20071127/elabInfoset.html
HT: I was only a while ago able to frame this compositionality of XML documents in a formal way ... please forgive the lambdas
<DanC_lap> Compositionality, elaboration and XML document semantics by Henry Thompson (28 November 2007)
[Tim cut-and-pastes something from the above PDF, but IRC clients mangle it] can't find lambda
HT: I think there is a formal
apparatus which supports the ... multiple vocabulary XML documents,
which would be fully general.
... The need comes from the fact that any new XML vocabulary might
arise which has to be elaborated in some way [or are quotes and stop
elaboration].
... I am happy for HT being recorded as shepherd for this.
<DanC_lap> (XProc is sequential?)
HT: This will become timely in the
next quarter, as the XML Processing model WG was charter to do two
things: to make a scriping language -- which is in CR -- amend to do
the default processing model.
... The WG has been reluctant to address the default processing
model, as we didn't think we know what that meant.
... The chair may well ask the TAG to tell the group what it
means.
... I am motivated to take this forward a bit.
<masinter> http://larry.masinter.net/temp-ht-compositional.html for now
<masinter> converted PDF to HTML [but equations mostly lost]
HT: Not sure how this connects to other web arch questions and issues
<johnk> this issue is related to http://www.w3.org/2001/tag/issues.html?type=1#mixedNamespaceMeaning-13
<Zakim> DanC_lap, you wanted to note GRDDL went to REC with a "we hope the TAG solves this someday" pointer and isn't having much pain that I know of; and to ask if the XQuery community
DanC: The GRDDL WG went to rec without solving the default processing model issue. eg do you do xinclude before or after grddl?
DWC: IN fact implementations have a
runtime command line -i flag
... tell me about XQ -- did the XQ groups solve this?
HT: They just ok with a data mdel and do not address how the data model gets there. they do not address how xslt:document() works or what it actually does
HT: In practice this is being handled on an ad-hoc basis
<Zakim> masinter, you wanted to ask that "Semantics" be qualified by context and perspective -- semantics of X to whom when seen where?
LM: When you say "the semantics of x" you must be careful to say the semnatic sof what to whom.
HT: That is why there has been slow and limited progress in this area. That is a tar pit.
<Zakim> noah, you wanted to relate to self-describing Web
NM: Any connection to the
self-describing web finding? I think so.
... It is about how to find which spec you need to apply at which
point.
<masinter> https://share.acrobat.com/adc/document.do?docid=ccf2b3b7-d115-414d-ad8e-c9681e58c36f [another rendering of the compositionality document]
NM: The media type description could say that the XML spec applies to this, and that if there is a ns qualified root element then several things are true
NM: 1) You can apply this kind of
reasoning
... 2) The XInclude spec applies
... 2a) Someone has given you an xinclude document
... 2b) There is a XInclude output document from applying the
xinclude.
... Have you transmitted that data? Is it part of the document? ..
[missed]
HT: Yes, suppose the xinclude element is inside a bit of rdf which is inside a bit of quoted RDF XML literal, then there is a question as to which trumps which.
NM: I have always assumed that the top down approach applies
DanC: That is what is not written down and what we are trying to write down.
<masinter> we're getting to the point that i want to the make the "TAG shouldn't do research" speech
HT: I have not found any expression
of that which isn't too complex
... and when I tried to do it it used a lot of lambdas
NM: How about: There is a standard style in which you document the meaning of your element. You can do it with or without invoking the recursive eleboration of the contents.
<masinter> describing the semantics of documents and the meaning of postings is a serious deep research problem in the extension of linguistics to acts of the web, and is a hard problem, and we should admit that solving this is a research problem TAG doesn't seem to be able to solve
<raman> given this is unresolved for such a long period, should it remain a TAG issue for the present TAG, especially given that folks like XML processing could also address this. Note: I'm interested at a technical level in this solution, but I dont see us making progress.
tim: Would the TAG be prepared to say that the document should by default be processed top down?
<Zakim> ht, you wanted to talk about uptake wrt xinclude and decrypt
HT: this is important to the W3C as actually XIncldue and XML encryption have languished largely because this has not been solved.
<DanC_lap> (I'm not aware of anybody who's more likely to deploy xinclude nor xml sig if the TAG resolves this)
HT: People neeed to be able to just rely on the processing, assume it without everyone having to specify every case in every new spec.
<masinter> 1+ XInclude and xml encryption don't depend on this
HT: Specs should be able to start with
this richer notion.
... Signatures and xincldue and decryption are just not plumbed
in.
<johnk> XML encryption and signature processing order is defined in WS-SecurityPolicy FWIW
LM: The TAG should not do research, we should do architcture.
<raman> larry has said what I wanted to
LM: Sometimes these questions are as
hard as hard philosophical questions.
... researchers belong on the TAG to bring research results to the
TAG but the TAg should not do research.
<jar> but there is existing research on this. sprinkled through POPL over the past 25 years
LM: I don't think XInclude depends on the solution to this problem.
<DanC_lap> (no, that question about signatures is not bigger than the problem of semantics. it's the same problem.)
LM: Signatures have a stronger need than semantics.
TVR: We should put research questions out to the research community. But lets get them off our plate.
HT: I think the dsposition of this issue has to begin by settling the question we have had 2 opposing positions on. Noah and tim have said this isn't a big deal, just state it. LM has said it sounds too complicated.
TVR: Versioning is another area we could [throw?] to research.
Ashok: There is a web servcies
security technical committee in OASIS which specifies policies
which spell out which part of a message ought to be signed or
interpreted, and whether you should sign before or after
signature.
... This is not research. This is a spec.
<johnk> WS-SecurityPolicy, specifically
Ashok: This is not signing for legal purposes ... only to determine whether it has been altered.
<DanC_lap> (well, to determine whether it has been altered as part of deciding whether to act and take some risk; so it's not far at all from the legal case)
<Zakim> DanC_lap, you wanted to try http://www.w3.org/DesignIssues/XML on for size again
<masinter> xinclude has some sercurity issues that a straightforward semantic interpretation might conflict with
<masinter> deciding what spec to write might be a research problem
TBL: So DanC, when I suggested a fairly simple definition of elaborated infoste where you can spec an xinclude EII as being the infoset of the document pointed to, and the semantics of html:p as being a paragraph whos contents is the EII of the its contents etc.. that would be simple... should we not do that .. why not?
----------------------- [ aborted due to lack of time ]
<DanC_lap> (I think I could only review it in an academic sense, but it's something that shouldn't be considered "done" until it's had some real users try to deploy it and such, Tim)
Tim: Propose to talk about it for a few more minutes
Real users, yes
<ht> Other point which I found leads to complexity is having to talk about what you're combining with 'XML functions'
<masinter> What's the smallest amount of this we could agree on and produce something useful?
NM: The bit henry says is problematic was explaining quoting in a way that doen't take 6 pages. Instead of saying that there is a rule which applies everywhere, to say that the rule is in your spec for your elements, if it is non-quoting, will appeal to.
<masinter> is this a clarification of the XInclude spec?
NM: If your element is a quoting element, it will just spec whatever it specs for the treatment of its contents.
[minuting lost]
<masinter> maybe there's something other than a 'finding'
<noah> FYI: Agenda has been updated to show error-20 tomorrow after morning break.
<masinter> about 'research': if we discover that something is a research problem, we don't have to drop it, we can write something that says 'this is a hard problem, here's our analysis, we don't know the answer but here is something that will help you think about it': document what we know and move on
<Zakim> ht, you wanted to mention fixed point as another tarpit
HT: There is a problem of fixed point that you must go on until you get to a fixed point because it is recursive.
Tim: No, i don't think there is
<masinter> HT: there's a tension between staying with the infoset, and accomodating vocabulary-sensitive notion of quoting. That really did screw it
<masinter> there's nothing in the infoset model that allows for quoting
<Zakim> noah, you wanted to ask about bounded set of specs
<masinter> HT thinks he might be able to make this work
HT: There is a problem with sticking with the infoset as domain is that quoting generates something different from the infoset.
<masinter> maybe this is just a problem with the infoset model
NM: I thought that maybe we should talk about 3 specific mechanisms
HT: The intention is to be
general
... not to just address three cases.
<masinter> is this actually an issue with XML encryption? Active WG, are they really asking for this?
NM: We must give people guidance on how to write specifications
http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2008-05-12.html
<noah> Actually, what I tried to say was a bit more nuanced. I think that helping the community learn to write specs that work well on the Web can be a very good thing for the TAG to do. In this case, I think we can share insights on how to handle the quoting and recursion, how to make XML self-describing, and how to make the specifications for individual elements compose well.
<jar> translate the problem into lisp, solve it there, then translate it back
<jar> much research on processing models for simple lisp-like languages
<jar> quotation, top down, bottom up, quasi-quotation, macros, static analysis, etc. etc.
LM: This won't work for signtures, they don't work with a top-down model
NM: Yes they do. (Example of xml Purchase order document on whiteboard. the semantics of the PO are declared to be void if the signature does not match.
<masinter> actually, they might be top-down, but top-down is different from one to the other
Asok: the signature can sign something outside the tree .. the top down model doesn't work.. Think about an xinclude in the signed bit.
JK: When you decrypt you map infoset to infoset -- signatures don't
<masinter> HT makes a good explanation about the problem with infoset replacement being a generic problem
HT: They do -- NM's example was wrong
-- people should be able to just sign part of a purchase order without the
PO spec being aware of that. The result of checking a sig is in fact
the document with no sig in it
... The point of all this is to foster orthogonality.
<Zakim> jar, you wanted to suggest requirements
<ht> NM: Can't treat signatures orthogonally, because the signature might be quoted
LM: If you have multiple signatures.
<noah> NM: I think there's only so much orthogonality you can have here, because you have to deal with the possibility that an ancestor of the signature element might have been a quoting element.
JAR: This is all familiar from the LISP world of the 80s.
<ht> HST: LISP has the domain==range property
<noah> NM: So, that's why the spec for the root element, and the specs for all descendents must at least say: "use the standard processing model for my children, no quoting"
<ht> HST wonders whether the domain==range property is important, or a red herring
JAR: Maybe we want to state some requirements and call for processing models, which would be a call for research -- or we could say it is an engineering queston.
<ht> HST has not (yet) been able to reconstruct why it was necessary (just desirable?) to interleave elaborated infoset 'construction' and application 'semantic' processing
<ht> HST thought quoting was it, and maybe NM's example will help
LM: If we think we don't quite understand the problem we should not prioritize this.
JAR: i would like to synch up with HT
HT: Sorry I didn't figure out what was wrong with the original proposal.
<Zakim> DanC_lap, you wanted to ask what's the start and stop of "the N point summary" and see if the answer converges
<ht> OK, so the pink box and the five bullets are coordinated in TimBL's conception [in http://www.w3.org/DesignIssues/XML], i.e. one recursion + fixed point pass
<ht> and the original draft was rejected because it required two distinct passes
random: http://www.w3.org/DesignIssues/Conneg
<noah> I think this issue is in pretty good shape. Henry has been informed by this discussion. Keep it open, medium priority, have Henry prepare new draft(s).
<masinter> I'm still not clear who needs the answer to this question
<masinter> please identify and ask them to tell us why they need this
<ht> And maybe quoting was one reason why the two can't be separated
<ht> DC: HST's compositionality paper might work better as a one page exposition and all the details in an appendix
<noah> From the TAG charter:
<noah> The TAG will [...] will [also] anticipate growth and fundamental interoperability problems.
<ht> ACTION: ht to Ask the XProc WG what their plans are in the area of the default processing model [recorded in http://www.w3.org/2001/tag/2009/03/04-minutes.html#action04]
<trackbot> Created ACTION-237 - Ask the XProc WG what their plans are in the area of the default processing model [on Henry S. Thompson - due 2009-03-12].
<masinter> one or more members of ....
<johnk> ACTION: John - Ask Security Maintenance WG about relevance of a default processing model [recorded in http://www.w3.org/2001/tag/2009/03/04-minutes.html#action06]
<trackbot> Created ACTION-238 - - Ask Security Maintenance WG about relevance of a default processing model [on John Kemp - due 2009-03-12].
<noah> ACTION: ht to alert chair when updates to description of xmlFunctions-34 are ready for review (or if none made) - Due 15 March 2009 [recorded in http://www.w3.org/2001/tag/2009/03/04-minutes.html#action07]
<trackbot> Created ACTION-239 - alert chair when updates to description of xmlFunctions-34 are ready for review (or if none made) [on Henry S. Thompson - due 2009-03-15].