See also: IRC log, agenda/TOC, Tue 12 Dec, Wed 13 Dec
Dave Orchard is expected to arrive in Boston midday
VQ: Considering minutes of 21 November 2006
NM: I think I should be listed as having sent regrets
Minutes being reviewed are at http://www.w3.org/2006/11/21-tagmem-minutes.html
<DanC_lap> (ed, pls send edited minutes as an attachment to www-tag)
<DanC_lap> (never mind)
RESOLUTION: Minutes of 21 Nov 2006 at http://www.w3.org/2006/11/21-tagmem-minutes.html are approved, subject to listing Noah and Henry as having sent regrets
<DanC_lap> 19 Dec OK for me
<Norm> 19 Dec OK for me
VQ: Any regrets for next week?
... No regrets for 19 December, so we will have a telcon.
... I've seen 6 regrets for 26 December, so that's cancelled.
HT: Regrets for 2 Jan 2007, as my office is shut; maybe could do from home if necessary.
<Norm> 2 Jan OK for me
VQ: Regrets from Tim from 16th, 30th of January. Some discussion of why we also have regrets for Tim for "30th of February"
NW: Regrets for 9th and 16th of January
VQ: Think I've seen regrets from TV for 2 January
HT: I'll come on 2 January if that makes the difference
VQ: We will have a telcon on 2 January
TBL: Tuesday 9 January at risk due to semantic web course here. Times for that aren't finalized yet.
... The regrets you were sent for 30th of Feb for me should have been for 20 Feb.
VQ: We don't have a date for next F2F, and there will be some turnover.
HT: There could be several new European members.
NM: It's occurred to me we don't use F2F travel to help with liaison with the community.
DC: Interesting, I'd sort of wondered whether it might be a benefit to someone who would want to host us that we could then meet.
<Norm> DanC, repeat the name of the event please?
DC: Also thinking about South by Southwest Festival — might be able to figure out how to host in Austin.
<DanC_lap> "SXSW Interactive March 9-13" -- http://2007.sxsw.com/
HT: Nominations for the TAG are in, but not public just yet.
NM: Suggest we pick a tentative date for a meeting, but alert the election candidates ASAP.
VQ: We seem to have tentative proposals for UK and Austin Texas.
Lots of discussion of F2F alternatives. Tim's schedule is difficult, but we note that we can meet 1-2 March in Cambridge, and those attending the Enterprise Workshop at Mitre the two days before may find it convenient to have TAG meeting right after.
Noah remembers we need to tell Stuart about the meeting schedule. Since he's being appointed, he's not on the nominees list.
(Note that this resolution was effectively rescinded on Wed. afternoon after it became clear that Stuart could not make the meeting as proposed above. See the minutes of that discussion for information about the TAG's tentative plans for its next meeting.)
VQ: Too early to discuss following meeting. Let's discuss mid-Jan. when we know election results.
HT: Suggest we follow up on Noah's suggestion to notify candidates immediately.
ACTION: Vincent will notify all TAG nominees of March meeting when nominations list becomes public [recorded in http://www.w3.org/2006/12/11-tagmem-irc]
VQ: Noah sent a note about putting passwords in the clear later on the agenda, but I want to keep it first to work around availability of participants.
NM: No problem
<DanC_lap> (agenda looks ok to me; on semweb arch, I'm sorta interested to present the rules in the GRDDL spec.)
VQ: I added something about the participation of the TAG on behalf of the workshop on Web services.
(although we were in principle doing an agenda review, we began a discussion of the Workshop on Web of Services for Enterprise Computing...)
There is a planned W3C workshop http://www.w3.org/2006/10/wos-ec-cfp.html
The workshop is 27-28 February 2007 MITRE, Bedford, MA, USA
VQ: Dave is representing BEA. Should we have someone there? Should we have a representative?
HT: Yes. It worked great at the backplane meeting.
VQ: BTW, was there a TAG discussion about the backplane meeting?
HT: We had a one hour call in place of regular tag meeting.
<DanC_lap> draft TAG position paper: "We have open issues on endpointrefs and whenToUseGet; some positions on those issues are summarized below. We're interested in your input"
HT: I don't think we need another call on this.
NM: Back to the Enterprise Workshop, the question is, should we prepare a position paper? My thinking is basically "no".
<DanC_lap> (if we closed EPR47, our issues list is out of date)
HT: It would be useful to summarize what the TAG's position is about Web Services vs. the Web; WS is overlapping but not quite the same as the Web.
NM: Is the overlap issue on today's agenda?
<DanC_lap> (ws-transfer is on this meeting's agenda as 3.4. Issue whenToUseGet-7 )
DC: My position is that we have open issues on whenToUseGet-7 and endPointRefs-47.
HT: By the way, no record of resolution of endPointRefs-47 closing?
DC: Well we sent them something, but I don't see an issue closing.
VQ: Did we not decide it was closing the issue?
<DanC_lap> from hugo... http://lists.w3.org/Archives/Public/www-tag/2006Jan/0074
<DanC_lap> Noah's msg is "TAG Request for Change to WS Addressing Core" 25 Oct 2005 http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Oct/0004
<DanC_lap> cc'd to www-tag
NM: When do we decide if and whether I represent the TAG?
DC: Let's have technical discussion first.
... now?
VQ: Let's wait for Dave to do whenToUseGet-7
<DanC_lap> I see http://www.w3.org/2001/tag/doc/passwordsInTheClear-52.html v 1.01 2006/12/11 04:44:11
See issue at: http://www.w3.org/2001/tag/issues.html#passwordsInTheClear-52
<DanC_lap> "A server SHOULD NOT solicit any passwords in clear text."
<DanC_lap> "A client or browser SHOULD NOT transmit passwords in clear text."
<DanC_lap> "A user agent MUST notify the user prior to sending the password in clear text."
<scribe> New draft finding: http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
<Ed> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20061211.html (Member-only)
The draft finding proposes the following:
ER: Significant change is that MUST not send in clear has changed into a SHOULD NOT, because there are some exceptions, explained in the finding.
<Zakim> DanC_lap, you wanted to ask that references to the TAG be limited to the SOTD section
DC: I think references to the TAG itself should only show up in the status section.
NM: Content seems basically OK, I had some concern that the prose would benefit from a bit of cleanup. A few grammar issues, etc.
HT: I think we need to do a copy editing pass. I can do in next 24 hours.
ACTION: Henry to copy edit passwords in the clear draft within next 24 hours [recorded in http://www.w3.org/2006/12/11-tagmem-irc]
<DanC_lap> (if there's some editorial bandwidth, I'd prefer to have cited works such as RFC 2617 show up in the references section too)
(Scribe's note added during editing of minutes: Henry did indeed prepare an edited copy the next day; it is available at http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20061212.html and it includes both editorial cleanup and a reference to RFC 2617 as requested by Dan.)
<timbl> Noah: [introduces http://lists.w3.org/Archives/Public/www-tag/2006Nov/0089.html]
NM: The agenda shows a note from me http://lists.w3.org/Archives/Public/www-tag/2006Nov/0089.html about further defining passwords in the clear.
<Zakim> timbl, you wanted to want to very clearly exclude anything like unicode from being considers not in the clear ... crypto only
<Zakim> DanC_lap, you wanted to suggest putting review by the Security Context WG before a decision
NM: History is: I suggested saying more in Vancouver, others on the TAG didn't find that helpful, we then had some further on list discussion that led me to write my note. I'm aware the rest of the TAG probably doesn't agree with me on this, and I don't need to pursue it.
DC: Should we run this by the Security Context (?) working group?
ER: OK with me.
<DanC_lap> http://www.w3.org/2006/WSC/
<DanC_lap> let's request review public-wsc-wg@w3.org http://lists.w3.org/Archives/Public/public-wsc-wg/
ACTION: Ed Rice to alert Web Security Context Working Group (chair Mary Ellen Zurko) to content of passords in clear draft, to negotiate a review by them, and to the fact that we are working toward publication. [recorded in http://www.w3.org/2006/12/11-tagmem-irc]
VQ: The action to Ed "ER, accepted on 21 Nov 2006: Produce a new version with these changes." is CLOSED
<timbl> ^ message from PaulC
<timbl> containing typos
<DanC_lap> Date: December 11, 2006 10:23:39 AM EST
DC: Paul Cotton has sent a message to TAG with editorial suggestions http://lists.w3.org/Archives/Public/www-tag/2006Dec/0019.html
NM: Suggest that's input to Henry's copy editing pass.
DC: I sent mail. I liked the changes.
ER: I read only the changed stuff.
RESOLUTION: The draft finding on metadataInURI-31 at http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061204.html is approved for publication
ACTION: Noah to update status to make metadataInURI and approved finding. [recorded in http://www.w3.org/2006/12/11-tagmem-irc]
ACTION: Vincent to announce metadataInURI draft once it's in final form [recorded in http://www.w3.org/2006/12/11-tagmem-irc]
VQ: Reviewing actions relating to metadataInURI
... "DC, accepted on 4 Oct 2006: Review security section on risks of serving executables as .jpeg to metadataInURI draft. Confirmed on 14 Nov 2006" CLOSED
... "NM, accepted on 14 Nov 2006: Rework metadataInURI 1st example to be more explicit as per Tim's suggestion, and update GPN per Dan's suggestion." CLOSED
... "HT, accepted on 14 Nov 2006: Seek a copy of the official court record of the UK case on ../../ etc." Propose to leave open. Nonetheless, CLOSED
... Henry is free to continue to research the legal background should he wish to, but there is no formal action for him to do so.
RESOLUTION: Issue metadataInURI-31 is closed.
***BREAK***
DC: I have a GRDDL case I'd like considered
<DanC_lap> MM 23 Nov
See email from Murray Maloney at http://lists.w3.org/Archives/Public/public-grddl-wg/2006Nov/0127.html
From that note:
<?xml version='1.0'?>
<document xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:grddl="http://www.w3.org/2003/g/data-view#"
grddl:Transformation="grokDisclaimer.xsl">
<p>120 Mz is adequate for an average home user.</p>
<xi:include href="disclaimer.xml"/>
</document>
disclaimer.xml contains:
<?xml version='1.0'?>
<disclaimer>
<p>The opinions represented herein represent those
of the individual and should not be interpreted
as official policy endorsed by this organization.
</p>
</disclaimer>
DC: Note that the "disclaimer" is included by reference.
... GRDDL extracts disclaimers, and produces different results according to whether xincludes run.
... Murray says there are options:
... 1) Always do XInclude
... 2) Let GRDDL say whether to do
... 3) Put out triple that says "there was an unprocessed XInclude"
... Does WebArch say any of these is right or wrong?
HT: Part of the input the pipeline WG received, either from TAG or from Tim (I can't remember which), tasked the workgroup to say whether there should be a default processing model.
... Norm and I have a long standing intention to bring the pipeline group back to this as the language comes together
... There are questions about how much control you have with respect to at least the following:
... 1) XInclude
... 2) Validation
... 3) Decryption
... 4) XSLT
... 5) GRDDL
<ht> http://www.example.com/foo.xml?1=xincl&2=xschema&3=xslt
<timbl> HT: That is not the right answer
HT: You could imagine a URI like http://www.example.com/foo.xml?1=xincl&2=xschema&3=xslt that means first do XInclude, then Schema, etc.
... Seems not quite right, but interesting
... Suppose I fetched an XML document and in accept header said I want application/rdf+xml. Application has rdf+xml
... Suppose there's regular application/xml with GRDDL stuff on the root.
DC: It's consistent with it.
... Haven't seen software to do it.
HT: Suppose I say I want application/xml and there's a stylesheet processing instruction.
TBL: Interesting ideas.
<timbl> TBL: The w3.org site could be asked to experiment with htem ... but relevance to this question?
HT: It's not clear to me that accept headers can do what you want
... Maybe we need to specify a standard default order
... Maybe include, validate, decrypt
... Then if the media type is application/xml you're done, if application/rdf+xml then do the GRDDL, etc.
... Still need something to do the non-default order.
<Zakim> Noah, you wanted to say the question is whether you're getting representations of the same resource...and that constrains use of the PIs etc.
NM: I think this is all OK if and only if what you're getting back is a representation of the named resource.
... GRDDL seems OK from that point of view.
... PIs for XSLT may or may not give you a representation of the same resource, but mostly probably do
<Zakim> timbl, you wanted to (a) point out that all XInclude, XSLT templat emode, decryption etc MUST be done top-down not in a particular order, but that (b) weird added things in the
<Zakim> DanC_lap, you wanted to suggest that we discuss xmlFunctions assuming all we have are static files on HTTP servers.
NM: Seems to fit with Generic resources...can have name for generic and individual.
DC: We're talking about client side processing.
TBL: At the client, pipelines aren't the issue. Processing must be done top down in XML.
... Thus, things like PIs are sort of kludgy because they're not cleanly in the tree
... Thus they need to be defined specially.
... Seems clear to me that all XML elaboration such is including must be done before GRDDL.
... If you're building software that does encryption and ???, it would be silly to do it in a way that couldn't be processed by generic software
DC: Suppose I just want to do decryption, is that antisocial?
TBL: No. What's antisocial is to sell software that does two or more of these but requires only in the non-natural order.
DC: What if I do only XInclude?
<timbl> clearly in a water not coke phase
<timbl> :)
NM: I think you can do lots of interesting things with a document. What's important is that there is only one core "meaning" of the document on the Web. You can write software that do other things with the document, you just can't say it's giving you the "meaning".
... e.g. there are good uses for digital signatures on both the form with the Xinclude and the transcluded
<timbl> <x:include src="data:text/plain;s/red/blue/g">
HT: I like Tim's answer is the right one, but there isn't consensus in the community on that.
... Noah's point is also correct. If we define, say, a "primary infoset"
... Interjection: one thing to say it's top down, it's another to say it goes until known fix point.
... What do you do if you find more than one signal on the same node in the tree?
... The second thing is, does it not only apply top down, but do you iterate on the result until done.
... Consider decryption and inclusion as the obvious.
<Zakim> timbl, you wanted to talk about quoting
HT: Suppose the result of the decryption is itself an XInclude, do I replace it?
TBL: The recursive iteration top down is controlled by the semantics of each element.
... XInclude semantics are the semantics of what you get by including me.
HT: I think the point Noah was making is also valid.
<DanC_lap> (timbl said "you can't have more than one dispatch mechanism; it has to be the element name" and ht tried to interrupt and note that this excludes GRDDL, which uses a mix-in attribute. HT didn't get the floor, but I think it's worth recording.)
HT: It should be possible to have a name not only for the "primary infoset" or true meaning, but also for e.g. the one with no processing. In that sense quoting from outside.
TBL: There are various reasons we need to hang things at the top level. This shouldn't happen as we go down.
... Given that attributes are unordered, hard to see how you'd make something general at the top.
... Can we say XSL stylesheet gives human readable but GRDDL gives semantics.
HT: The XSLT PI need not necessarily give human presentable.
DC: What do you do with it?
HT: e.g. style that?
... The Web browser shows me the raw XML.
... I do that for debugging.
NM: Working as designed. He's getting an XML representation of the resource.
DC: Does this mean GRDDL did the wrong thing?
HT: Thank you, I really wanted URL for first do the XSLT (producing the XML) then do GRDDL.
DC: The W3C happens to run a "fancy" HTTP server that does that kind of stuff, with a URI that has the URI of the document in question in the query string of the service's URI.
HT: Right. I was noodling on the plane with "can't we do better?"
... This really is about this resource, so it seems desirable to base the URI on that.
TBL: There are tools at the W3C web site like, validate that you can use to create a new URI.
DC: Right, but these are local conventions.
TBL: What's your proposal?
HT: I'm happy with an answer like yours. We specify an order for the "broken" stuff at the stuff at the top. We specify rules for recursive processsing of the rest.
<timbl> what is your proposal for XSLT PI vs GRDDL
HT: I don't believe either XSLT or GRDDL are part of the primary interpretation of the resource (resulting in the primary infoset)
... The elaborated infoset should include only XInclude, Validation, Encryption
<Norm> Validation by what method? Schematron?
HT: Recursive walk gives you everything except maybe validation.
<timbl> The elaborated infoset is top town and does decrypt, include, in-line cslt
HT: Could argue validation triggered by attribute and therefore weird.
NM: So it's only those 3. No user extensions.
HT: No, just those 3.
NM: Feels wrong.
TBL: Is wrong. Needs to be extensible. A new processor looks at the namespace.
(Noah thinks it should look at the QName)
HT: We can say that XML encryption namespace is an elaborating namespace. An elaborating processor performs the algorithm we've described.
<timbl> an elaborating processor will elabrate an element which is a an xml function.
<timbl> xslt functions, encrypted elements, x:include are examples of xml functions
HT: Question is, how does someone say "I want the GRDDL'ized version?"
<Zakim> DanC_lap, you wanted to note my preferred choice for the GRDDL spec: both GRDDL results are licensed; the author clearly meant the result of inclusion, but must accept that some
TBL: GRDDL spec should say that it's working on the elaborated document.
DC: Prefer both interpretations acceptable, with elaborated preferred.
TBL: In the GRDDL community we could just say, "do XInclude". Can you implement it using XSLT?
<Norm> You'd need XSLT 2.0 to get parse=text
HT: Almost. There are a few aspects of namespace fixup. Can't do them with XSLT 1.0, maybe or maybe not with 2.0.
DC: Could HT find that mail exchange.
HT: Yes.
NM: Tim, doesn't your proposal require GRDDL processors to correctly ID all eloborating namespaces?
TBL: That seems too strict.
<ht> The XInclude in xslt thread is herehttp://www.biglist.com/lists/xsl-list/archives/200610/msg00563.html
DC: Look, even just XInclude would probably sink GRDDL.
<Zakim> Noah, you wanted to ask how you put a DSIG in the document with this model?
<DanC_lap> s/sync/sink/
<ht> This is the critical message, which identifies the things in xinclude that xslt can't handle: http://www.biglist.com/lists/xsl-list/archives/200610/msg00672.html
NM: If we allow GRDDL to not do all this stuff, then I think the GRDDL author needs to be responsible for all possible interpretations.
TBL: Not in an enterprise where you know the application.
NM: But on the public Web, I think you have to take responsibility for all interpretations.
... I am a bit concerned about things like DSIG where there are pressures to put the signature outside the content that's signed, e.g. following it.
<Zakim> Norm, you wanted to say that you might sell me on XInclude and maybe decryption, but not on validation
NW: I don't think validation fits as part of the default elaboration; first of all, which one would you privilege?
NM: W3C Schemas augment infoset.
HT: So do DTDs.
DC: DSIGs have XPath that let you put the sig in the thing being signed. Cute.
NM: Can look out, e.g., to root. Not functional.
DC: Why not functional?
NM: In some sense, whether the root is there depends on whether signature checks.
DC: Or you could view that as just a policy issue. The root is there in any case, whether to trust it is an application issue.
HT: Other interpretation is the document doesn't mean anything except "failed sig" in case the signature fails.
NM: I think both intepretations are potentially sensible, which is why I called this out as an issue that benefits from some attention.
TBL: Shows diagram of building elaborated document in manner described above.
DC: People aren't doing that with GRDDL, and I'm not convinced they will. They won't want to do XInclude
<DanC_lap> DC: so the author has to accept that some won't do xinclude/elaboration.
<DanC_lap> TBL: yes.
HT: How do we name the version with another interpretation.
NM: But the interpretation needs, in general, to be orthogonal to the characters in the URI.
TBL: Vectoring on the document type at the top is important.
... Similarly an HTML spec should say that it's a member of the functional style languages.
NM: Do we need to invent a media type for each combination that matters?
TBL: The proposed requirement is wrong. The document means what it means.
HT: What a particular web site does with, e.g. query strings, is up to it.
<Zakim> DanC_lap, you wanted to explore a simpler GRDDL design: push xinclude into the transformation (perhaps with XProc)
<timbl> norm?
<timbl> fn:doc
DC: fn:doc is in Query spec
... GRDDL spec editors draft refers to this.
<DanC_lap> .. http://www.w3.org/2004/01/rdxh/spec
<DanC_lap> look for fn:doc in there
DC: Green stuff is English
... White stuff (see below) is SPARQL N3.
Text
"If an information resource IR is represented by an XML document whose root node is linked to a GRDDL transformation TX, then TX is a GRDDL transformation of IR."
SPARQL/N3
?IR log:uri [ fn:doc [ grddl:txlink ?TX ] ]. ?IR grddl:transformation ?TX.
DC: Does spec call for XInclude processing?
NW: No
DC: Context seems to talk about "available documents".
... Market explanation is you don't do XInclude.
... Well, GRDDL spec, for the moment, defines in terms of fn:doc.
... What's the URI in the square bracket.
... see prose
HT: What is TX?
... I thought what you want is the document you get by transforming...
DC: No it's not...hang on.
HT: OK, so TX is some miscellaneous transformer, e.g. XSL stylesheets.
DC: This is the rule I'd change if I wanted to, I could define an fn:doc that produces elaborated infoset
... There is an open issue, but right now, the GRDDL spec doesn't say do XInclude unless your (?? scribe missed this??) does it on its own.
HT: My answer to GRDDL working group doesn't change: you shouldn't write a normative dependency on the elaborated infoset into the GRDDL spec.
TBL: Why?
HT: Too early.
TBL: Partly people don't implement XInclude because we haven't said where.
NW: You can just set it in Java JAXB 1.4 that will do it transparently.
... Error if they fail.
VQ: Where are we on xml function.
Henry: My name is down against the next step and I'll try and do something.
Tbl: I'd like to see someone write something down that says that if your going to use xinclude to put it in fmdoc
<timbl_> or in its successor fn:doc2
Henry: what we could say is 'use the elaborated infoset' and do it in an extensible way.
Tbl: at the moment we don't have definition we can just write software for.
Henry: there is a cphoneularity here. Documents which are properly addressed from a top down-approach will be properly addressed.
Henry: I thought the answer is: you start at the root and you perform the following along.
Tbl: but how is it going to know?
Henry: There is an easy way and a hard way: The easy way is to say 'here are the elaborating elements'
Henry: all you need to name is xinclude and ..
Tbl: no..
Tbl: its not the embedding spec that uses doc2
Tbl: if I introduce a new version of html which insulates from any further processing. Like an imbedded rdf.
Henry: The only road I think we should spec is the easy one. These are the elements, these are the semantics and then we're done.
Tbl: when they move from doc to doc2 that's irrelevant because the rddl spec references doc
Tbl: but suppose html1 uses doc and html2 uses doc2, then the grddl spec would need to be updated to reflect doc and doc2.
Henry: I think the answer is; for html purposes, if your an html application. That you use the doc2 and if your a grddle app then your processing xml generically and you would get different answers but I don't see how you could beat that.
Henry: you cant expect the grddle spec to say 'decide what to do based on ..
Tbl: as an alternative: always use doc2 except for a few limited cases. You dont use for xml and it assumes that any other xml document will use doc2 if you implement doc2's features. And if there is anything which involves quoting then you stop the elaboration.
Tbl: there are not many markup languages that use that anyway.
Henry: I thought thats where I thought we were.
Henry: it doesnt matter what the html spec says (use doc1, doc2, doc3) instead if your using grddl use doc2.
Noah: what I thought we were trying to trace down is that if you use a get, you should be very well able to follow-your-nose and get a very well defined meaning from this document.
Noah: and the piece that keeps missing is the 'media type'.
Noah: The media type spec should be the starting point for defining each media type set.
<Zakim> Noah, you wanted to bring up media types yet again
Noah: then in the grddl spec you reference the other spec directly.
Noah: and this feels like the right way to discuss this.
<raman> for us on the phone, if you guys talk at the same time, it's impossible to follow *anything*
Henry: We should actually consider the way to do this is to introduce an entire family of media types svg+html etc..
<DanC_lap> (new media types as HT describes has a certain appeal; it's consistent with my sense of the cost of deploying any of this stuff.)
<timbl_> I note however that Miozilla does not still key off the "+xml".
Noah: I hope we can get through with just a few media types
<timbl_> let along exml
<DanC_lap> exactly; it will be a long time before mozilla does anything like doc2
Ed: tag welcomes Dave O joining the meeting
Tbl: People done accept the +html actually has html in it.
Dan: They dont do the .txt fallback either.
<DanC_lap> (it's more of a text/* than a .txt fallback)
Henry: There is no doubt there are practicle problems, but I think Noah is right.
<Noah> My point is that I think the opportunity may be to put into existing media type specifications, such as RFC 3023, the specification for the mapping from the transferred representation into the Infoset of the "preferred implementation"
Tbl: I think its really valuable to have the default be one thing.
Tbl: view source, view elaborated source, view collaborated source.
<Noah> The media type spec seems to be the architecturally right place to set out the interpretation of a typed representation.
Henry: The implication of that, which I think we all assumed, is that this is a client side mannor
Tim: no
Henry: Then view source cannot be the answer if its client side.
Tim: We've talked about both.
<Zakim> Raman, you wanted to ask what is the impact of client side modes to the DOM
Raman: I don't think we're answering the question, what gets expanded when.
<DanC_lap> (it's pretty darned clear today what document you get for most URIs)
<DanC_lap> Raman: what about javascript [interesting question.]
<timbl_> onload()
<DanC_lap> (yes, onload/document.write is quite analagous to xinclude)
<ht> document.write has same problem
Raman: if I open a web application, say a calendar and the document comes over as html/java script and then some part of the page I type in a date which runs a java script handler. This java script now inserts into the page a new part of markup.. so if I view source which source am I supposed to see?
<DanC_lap> (it's pretty clear to me that the design space is sufficiently non-trivial that GRDDL shouldn't touch it with a 10 foot pole.)
Raman: this is where the most difficult problems are, this is where we answer the java script problems.
Henry: we have to have an answer to this problem in the html space that works in the html space. I think it would make it incredible difficult to answer the question when these spaces haven't been defined first.
<Zakim> ht, you wanted to give the hardline answer: no, no and no
Henry: The origin of the process is a well formed html document, and if it is, its native semantics are irrelevant to what the grddle process does.
<timbl_> <x:include src="data:text/javascript;socument.write('<x:include src=foo.xml />>')") />
Henry: We're talking about the case where an http GET is being done by a grddl process, not where its being loaded by a browser.
<DanC_lap> (I agree with Tim that <div>loading...</div> gives you what it gives you, which is nothing because you didn't run the javascript; but probably not for the same reason Tim does. The reasons for me extend to the xinclude case too.)
Noah: two decisions can be made. The java script is there, but its not fundamental. Or they can say that the preferred interpretation of this page is to perform the on-board javascript and process the resulting page.
<Zakim> timbl_, you wanted to suggest that <x:include src="foo.html" /> generates a triple <> rdfs:seeAlso2 foo.html
Dan: reference option3 in Murry's message.
Henry: its my book and I xinclude all the chapters for my book.
Dan: Yes, so you'll get an assumption that every xinclude is a chapter in the book.
Tbl: grddle is designed to work on some microformat for example. so you could describe each chapter, each chapter has the following attributes (by the way xinclude chapter3)
Dan: so this sounds like a nessisary answer. We have to allow people to do this.
Dan: So if your writting an grddl interpreter you have to put xinclude in there.
<Henry> GRDDL will allow me to identify a pipeline to do the computation
Tbl: What happens if they write one which doesnt include the xinclude
<Henry> So I just use a pipeline which does XInclude, then runs my stylesheet
Henry: We should talk about where we think the world aught to be. We have a definition of an elaborated infoset and thats where you start.
<timbl_> We should xinclude+decryp+xstltFunction then grddl
HT: the answer to Murray's question is option1. grddle is defined on the vanilla infoset.
Tbl: but xinclude is defined, its two lines to add it to grddl
Noah: your defining an document which points to an xslt style sheet but its not self describing because there is not spec that says you can follow-your-nose to this sort of document.
Henry: I have to defer to Norm on this.
Norm: I don't know the answer to that question.. the xslt2 processor is conformant if you write a validation process prior to the xslt2 process.
<DanC_lap> (so given doc1.xml and txform1.xsl2, there are several correct answers for the output? whee!!)
Noah: but for the self describing web to make sense. To get the preferred interpretation you need to answer the question 'where' to get the documents.
Noah: because all these things effect rather dramatically where you get these documents from.
<Noah> I think Dan is making exactly my point. I.e. since there is that variability, to get to a single normative preferred interpretation, we need to lock down those points of variability.
<Noah> That seems to include, whether to schema validate, and policy for locating schema documents to use, and also what is a fatal error.
Norm: Dan's point is correct.
<DanC_lap> (do you guys admit this multiple-answers-are-correct stuff i the XSLT2 test suite?)
<Norm> I'm not sure wrt the test suite
Henry: I think we had consensus that neither grddle or xsl style sheets were candidates for the elaborated infosets.
<Norm> If your stylesheet cares about types, it ought to HCF if there aren't types.
<Norm> I mean, you ought to write it that way.
Noah: there are other reasons to raise the schema issue, such as defaults. My guess is that users would want them included.
Dave: The problem is encryption is a really hard thing, since there may be multiple encryptions.
Tbl: we're talking top-down interpretation. So if you want to process encrypted data you have to decrypt it and then process it.
Dave: but we don't have a way to tell the processor which parts to 'do'..
<Noah> So, Henry and I were talking past each other a bit. I thought that XSLT was under consideration for the preferred infoset, I was saying that might bring along a need for schema processing for XSLT 2.0.
<Noah> Henry clarified that he doesn't think XSLT is under serious consideration for that anyway.
Tbl: whenever you process this, always start out by doing the includes, then apply the style sheet and thats the order that you should always do things.
<DanC_lap> (wsdl:includes? wsdl didn't use xinlude? oh yeah; neither did XSLT nor XML Schema. And I don't think there are any good uses of the generic application/xml media type; XSLT should have its own media type, for example. So all this generic-XML stuff has no basis in practical reality.)
Dave: but I was making a bit of a jump to where languages do a bit of this on their own.
HT: so start from the elaborated infosets and then carry on.
Noah: what you need to say is you can take it as far as you can take it, for example sometimes with credit card info you cannot decript all the way down, so sometimes its ok to process based on a partial doc.
Tbl: lets say you have a part at the bottom of the doc that needs to be decrypted, you process everything fine until the very bottom of the document where its encrypted.
<Zakim> ht, you wanted to say partial success is well-defined
Noah: if thats the case then there is another infoset which includes encrypted data.
Henry: We just wanted to say that the elaborated infoset includes decryption, however that includes out of band information (key) so you may need to define the infoset by the set of available keys. This means that if you dont have a key, you do what you can and the rest is acceptable.
Ed: ht: so I think we're done with this and I think I should go off and write something.
<DanC_lap> . ACTION Henry: draft a finding on xmlFunctions-34
<DanC_lap> discussing NW, accepted on 6 Dec 2005: with help from HT, produce a draft finding on XML functions in January [2006]
<Ed> ACTION: Henry to create a draft finding on xmlFunctions-34 to the working group by the 8th of Feb. [recorded in http://www.w3.org/2006/12/11-tagmem-minutes.html#action06]
<Ed> ACTION: Norm and Tim to review Henry's draft. [recorded in http://www.w3.org/2006/12/11-tagmem-minutes.html#action07]
Ed: Note to withdraw previous actions on this item replacing with above action.
<DanC_lap> # NW, accepted on 6 Dec 2005: with help from HT, produce a draft finding on XML functions in January [2006]
<DanC_lap> # TVR, accepted on 27 Feb 2006: summarize history of DTD/namespace/mimetype version practice, including XHTML, SOAP, and XSLT continues
<DanC_lap> TBL, accepted on 27 Feb 2006: write a short email to make his point so we capture this for future DONE
raman: heading for lunch ...
Norm: Break over?
Vq: last issue was discussed and link to endPointRefs-47 was noted. Message from Tim end of Oct was the last note.
Vq: so what's the next step.
Dave: I spoke with Paul Cotton a couple of weeks ago, but no commitment our outcome from the discussion.
Dave: we need someone appropriate to answer from inside Microsoft.
Dave: I think there are two different worlds and I don't think that's doing the web any particular amount of good.
Dan: Well, then we've already posted our position on this then.
Dave: right, so I think there are some technical pieces missing there;
Dave: Diving into the use case of somebody doing a full wstransfer on a resource and they're going to make all the resources available. They're doing this using EPR's, with reference parameters.
Dave: There is nothing available that can use HTTP and get to these same EPR's since there is not EPR to URI mapping.
Noah: This is being essentially 'parked' as a spec so that further complicates things.
Dave: they did not look at this as their job to define any bindings. They consider this done.
Dan: so why did they use bindings in the first place?
Dave: So I think the reason why people use EPR's for reference parameters because the tooling makes it easy.
Dave: one of things that happens all the time. Using HTTP cookies/session ID's but these could also be put in URI's because the API's are just so darn simple.
Noah: remember this issue where soap processors do dispatching on qnames? I'm hearing that thats now secondary..
Dave: well, you could have two keys, like an employee ID and a Session ID. Both are in the soap header.
Dave: I think there a bunch of things tied into this, and I think Noah has reference much of this. The way that the wsdl takes a look at it makes it a little easier. people in the web resources area like to have a wsdl or method signature and we don't have a description language for rest for http which is widely deployed.
Henry: I don't understand. We asked them to put compromise wording in their draft and they did.
Noah: we have a submission, when it was submitted the W3C staff noted that there were some potential issues. The 1st example they used is a soap example which could have been reasonable assumed to have come from a URI.
Noah: but there is no working group. The w3c is having a workshop and there was discussion this morning to send someone from the TAG to go and discuss the TAG's position.
Noah: It could be as simple as 'see that email we sent' or it could be..
Dave: I didn't like the message we sent, I didn't think they were strong enough or forceful enough. I'm thinking if there was something there and someone besides just Microsoft would implement it.. if the w3c would just publish it.
Noah: I think the issue is that when you want the higher level things that are packed in SOAP and try and nogotiate this in REST then its harder. We do have all the specs to do this though.
Dan: Yes, but its not good enough to say we can do this, we need to come up with something like 20 times better to get people to do it.
Dan: one aspect is that people who write REST services don't write wsdl's because they're kind of wiz-bang programmers and they dont have to.. but now descriptor languages are starting to pop up around these as well.
<timbl_> No, looking fro info on yahoo services in the ws sense
Henry: the soap interface is so much easier because you can schema validate and test the results.
<Norm> WADL is Marc's language, right?
Dave: The TAG should say the WDDL team should develop a web descriptor language.
Dave: wsdl2. can describe web resources
Dave: we've tried to make everyone happy and kind of buttoned everything together, but I dont think we've made anyone happy.
Henry: how does this effect the qname issue?
Dave: wsdl deals with it one way and WDDL another, but both can deal with it.
Ed: why are we trying to get HTML and SOAP to be the same.
Henry: defining things with URI's has huge benefit.
<DanC_lap> Introducing WADL Posted by mhadley on May 13, 2005
Dave: we see this in almost every customer engagement now, what's the difference between REST and SOAP? And so what the cost is that there are fewer services being deployed than there aught to be.
Dave: given the amount of money being spent on doing this.
Ed: I think this is because most people don't know how to write a services based system
Dan: I think WADL will help with this.
Dave: So the WADL idea is one solution.
Dave: I think we should encourage a simple widely deployable descripion language for web resources.
Ed: so is SOAP is fundamentally broaken?
Dan: I dont think we said that. WSDL was trying to fix too many issues at once. The way that today's tools utilize soap results in far less URI's than we think there should be.
Noah: I think even the stuff we spec'd for it which made it less broken wasnt implimented.
<DanC_lap> http://www.w3.org/2001/tag/doc/whenToUseGet-20030922.html#webservices
Dave: we should focus on use cases.. this is why its painful and so .. wsdl.
<Norm> Vincent, I have to cycle to the garage to get my truck before 5p
<Norm> Vincent, do you want anything from me before I drop off for the day?
<raman> back
Dan: the current situation is that you need to decide http get or SOAP and they're really not interoperable.
Dave: the 2 other things we need to capture; we're in the web services camp, using the web services tooling and its just a pain because your used to the wsdl because they don't give you a description language.
<DanC_lap> (in particular, for get/lookup operations with <10 scalar parameters, I think there should be interoperability)
Dave: one is where your used to having a description and you get one. The other is where you get an english description and you get a technical one.
Dave: I'm writing a very similar paper for someplace else.
Noah: So, assuming we're on a downward hill toward announting me to go.
Noah: I could have something to the TAG by the evening of the 4th.
Dan: can you send the outline to the TAG this week?
Noah: I'll outline by monday and we can discuss on tuesday.
Ed: ACTION: Noah and Dave to write a position paper outline for the TAG by the 18th of Dec. [recorded in http://www.w3.org/2006/12/11-tagmem-minutes.html#action08]
Ed: Resolution: Noah will go to the WS Workshop to represent TAG
<dorchard> : http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/
<dorchard> web services workshop from 2001 http://www.w3.org/2001/03/wsws-program
Dave: So what else are we going to do on this ws-transfer issue.
<DanC_lap> http://www.w3.org/Submission/WS-Transfer/
<Noah> See text just below "The following shows a sample SOAP envelope containing a Get request:
<Noah> In section 3.1
<Noah> <wsa:ReplyTo>
<Noah> <wsa:Address>
<Noah> soap://www.fabrikam123.example.org/pullport
<Noah> </wsa:Address>
<Noah> </wsa:ReplyTo>
<Noah> <wsa:To>soap://www.example.org/repository</wsa:To>
<Noah> <xxx:CustomerID>732199</xxx:CustomerID>
<Noah> <xxx:Region>EMEA</xxx:Region>
<DanC_lap> "soap:"?
<Noah> So, I'm assuming there was a <wsa:To> EPR that had <xxx:customerID>732199</xxx:customerID> as a reference parm.
Tbl: Clearly you can write software that can make this work.
<Noah> A reasonable interpretation, I think, is that this example is putting identifying information in the reference parms.
<Noah> ??: What's the soap: URI scheme?
DO: It's the Microsoft soap over UDP stuff.
<DanC_lap> so http://www.example.org/repository?CustomerID= 732199&Region=EMEA ?
<DanC_lap> (meanwhile, on the soap URI scheme... [[6.1 Syntax The syntax of the URI scheme is as follows: soap.udp: // <host> [ : <port> ] [/ <rel_path>] [ ? <query> ] ]] -- http://www.google.com/url?sa=t&ct=res&cd=6&url=http%3A%2F%2Fmsdn.microsoft.com%2Fws%2F2004%2F09%2Fsoap-over-udp%2F&ei=L9N9RdblBoKMgALViZWwBw&usg=__r0xvBVsGTlVXP0mb5MnBJKGh_Wg=&sig2=gswyLcbVaaF0XzW7q9th7A
<DanC_lap> )
Dan: there is really nothing I can point to specifically that states they're doing this wrong.
timbl:_ which points to http://download.microsoft.com/download/3/8/2/382EAA0D-576E-4F2D-803A-22255A0C7251/DSSP.pdf
Dan: Groups this effects;
Dan: WebAPI, Math, Semantic Web Deployment, GRDDL, CDF, XSL WG, HTML WG, XML CORE, MuliModal, MobileBP, CSS, XForms
Dan: too many to discuss
Raman: Yes, I agree.
Tbl: so my hope is that we can map out a gentle slope that people can follow to get to where we need to be instead of major jumps
Dan: do you connect your cost metric to real world costs?
Dan: (add QA IG)
Tbl: you may want to use xml tools and explains the benefits of doing so.
Dan: you can make your 'page' feel better when you validate it.
Noah: when you get a 'score' you imply that its our intent to write cleaner and cleaner code all the time.
Dan: I read just recently a guy who maintains a really cool page on all the web standards. His whole page is in html4 but he avoids xhtml because while he thinks its a good thing, he thinks its just not there yet.
Ed: I don't think we've mapped out why these technologies exist and what their 'role' is.
<DanC_lap> cool page http://www.webdevout.net/browser_support.php <- http://del.icio.us/connolly/xhtml+quality
Ed: Dan: well, most (huge amount) of the web is HTML only, the rest have a minor point percentage of the market.
Ed: I think most people cannot tell how a page is created, just because it 'ends up' being html doesn't mean its not using xslt/SOAP/ etc..
Chair: Lets continue this discussion after 'our lunch' tomorrow?
TV: sure, that works
Chair: start tuesday at 9:00
Chair: 9:00 versioning issue
Chair: 10:30 web services
Chair: tag soup early afternoon.
Tbl: We may want to read http://lists.w3.org/Archives/Member/tag/2006Dec/att-0034/SEMWEB.html