See also: IRC log
We will have a telcon next week on 14 Feb 2006
No regrets so far.
Dan will scribe.
VQ: inclined to agree with Noah to defer
discussion of Principle of Least Power.
... anything else?
DC: We should be publishing something every 3 months on technical reports page.
VQ: OK, let's discuss at end in place of Principle of Least Power
Tim Berners-Lee joins the call.
<DanC> 8 and 41
DC: I would also like to discuss issues 8 and 41
HT: I'd also like to discuss Principle of Least Power after all, as I am just coming up to speed
VQ: Agenda should go quickly, it all should fit.
See draft minutes at http://www.w3.org/2006/01/31-tagmem-minutes.html
VQ: comments?
silence
VQ: I think one of the issues has a wrong number, but readers will probably get it. I'm OK to approve as they are.
TR: Sorry, do the issues have names as well as numbers?
<ht> Raman, issues are identified officially by name-number, e.g. xmlFunctions-34
VQ: Yes, see the agenda. In this case we are discussing the minutes of last week at http://www.w3.org/2006/01/31-tagmem-minutes.html
RESOLUTION: Minutes of 1 31 2006 at http://www.w3.org/2006/01/31-tagmem-minutes.html are approved.
<ht> ... But sometimes people just use the number - this usually confuses me too :-)
<DanC> sorry; namespaceDocument-8 and xmlVersioning-41
VQ: Suggest we divide agenda explicitly as we are meeting Monday afternoon and Friday afternoon
<ht> HST regrets for Friday of the Tech Plenary TAG f2f
VQ: Why separate meetings? Two reasons: 1)
accomodate scheduling conflicts and 2) review what we've learned during the
week
... input welcome
... I'll prepare a draft meeting page soon
<Zakim> DanC, you wanted to think out loud about "closing keynote" or "summary from the TAG" in the tech plenary minutes
DC: thinking about what it would mean to do a closing keynote for plenary. Probably not a good idea to actually give such a keynote, but it may be a useful way to think about focussing.
VQ: I note that some TAG members are not registered for Friday afternoon.
HT: I've already given regrets for Friday, as I have to leave Wed.
TR: I think I've registered for both days and will be there both days.
<Ed> I'll be there for both days as well.
DC: Our home page doesn't note this meeting under current events.
VQ: it's in the meeting section
DC: Current events listing would make clear it needs attention now
<DanC> registration
VQ: Roy will attend only on Monday afternoon,
not Friday.
... Tim, what about Friday?
TBL: I suspect I'll miss Friday. I had thought we were only meeting early in the week.
ER: Do we have critical mass for Friday.
TBL: Looks like I'm staying into Sat after all. I'll be there on Friday too.
NM: What about Dave Orchard?
<raman> need to step out for a couple of minutes, back in a few.
<Ed> http://www.w3.org/2002/09/wbs/35125/TP2006/registrants#tag
ER: He's signed up for both days.
<Zakim> noah, you wanted to discuss metadatainUri
NM: First of all, I need confirmation that you
all would prefer I spend next few weeks on metaDataInURI vs. SchemeProtocols
... anyway, two weeks ago I got some requests to pick up metadataInURI-31.
If I do, one option would be to discuss at F2F.
DC: Interested in nexus of Dave's versioning work, XML Functions, and self-describing Web.
VQ: We don't need to finalize agenda just yet anyway
VQ: We had a discussion last week about that with Norm (see: http://www.w3.org/2006/01/31-tagmem-minutes.html#item04 )
<ht> I just sent mail about my starting point for this: http://lists.w3.org/Archives/Public/www-tag/2006Feb/0013.html
VQ: Norm reminded us that Henry was supposed to work with him.
See note just sent from Henry at: http://lists.w3.org/Archives/Public/www-tag/2006Feb/0013.html
HT: Sent this to clarify my own thinking.
<raman> back.
HT: Propose to distinguish two terms: 1) What
I call the "XML Semantics" of an application/xml or text/xml document and 2)
the application semantics
... Difference is important.
... I think XML Functions is mainly about the second
TBL: For XML Semantics do you mean mapping to infoset?
HT: Yes.
TBL: I don't usually think of that as semantics in the strong sense we usually mean.
HT: Well, it's a mapping.
TBL: Well, we could also call the infoset an abstract syntax, in which case we're just mapping from concrete to abstract syntax.
<DanC> "xml abstract syntax" is more appealing than "xml semantics" in some ways, yes.
HT: More or less agree, can go either way.
<raman> One man's syntax is another man's semantics:-)
<Zakim> DanC, you wanted to say it's my goal to swap in DO's recent work on xmlVersioning-41 and work toward connecting that to self-describing web on xmlFunctions-34 and to say that I'd
DC: I think a significant point is that this story only holds for application/xml and text/xml. In the case of application/svg+xml I know much more. For example, I know about circles. Your email message talks about "The XML semantics is what you get initially from interpreting correctly a message whose Media type is text/xml or application/(...+)xml."
HT: Emphasis is on initially.
TBL: I still don't like calling this semantics.
HT: I want to switch to the meat of this, which is that I'm trying to figure out how best to deal with things like XML Base, XInclude, xml:id, etc. Want to talk about that, before we get to "compositionality" [sic].
<Zakim> DanC, you wanted to recall (from where? I forget) that xml:base has to be explicitly cited in the application semantics, though I can imagine a "consent of the governed" approach to revisiting that.
DC: My impression is that XML Base is not part of XML semantics. Each spec has to cite it explicitly if desired. Future specs could go further, but that seems to be where we are.
HT: agree. xml:id tried harder to be in the middle, and thus is tricky. We've discussed a "baseline processing model" that might include XInclude.
<Zakim> timbl, you wanted to say that another layer will not appear above te infoset but inclduing say XInclde, because Xinclude interpretation involves understanding of the XML function model completely.
TBL: While we want to see these things widely used, we've seen that we can't blindly apply all of these "first". We've got things like quoting to worry about. I don't think there can be a simple intermediate form that just gets all the XML-related mechanisms have been blindly applied. XML Functions teaches us that we have to know where something like XInclude appears to know whether to process.
HT: A bit curious that quoting is the only example. Is that a bad thing?
DC: No, we shouldn't be surprised that quoting is special.
HT: If quoting is the only reason, then we should treat quoting specially, and have a phased story for the rest.
TBL: What do you mean by phased story?
HT: I meant: what you described as doing all the XML'ish stuff first.
TBL: Do you want to make the quoting stand out in the syntax?
HT: That's a way to do it.
TBL: Not done in XML.
HT: A bit more on compositionality: my initial cut at composition didn't get a supportive reception in Edinburgh.
TBL: Where do you set it out?
HT: in the message we're discussing.
<timbl> "Compositional semantics" is defined in http://lists.w3.org/Archives/Public/www-tag/2006Feb/0013.html ?
HT: See example in the note:
" the interpretation of <xhtml:a href="http://www.example.org/...">...</xhtml:a> is independent of its position in an XHTML document tree.
NM: What about xsd:element?
HT: Not convinced that's a counterexample.
TBL: You're talking about transforms you can apply leaving the meaning of the message invariant, but I don't know how to judge what "means the same thing" in all cases.
HT: Consider Python, which has compositional semantics. The semantics of things that appear on either side of a "+" sign don't depend on the "+" itself.
TBL: Well, the expressions can be evaluated independently, but what to do with them comes from the operator.
HT: That's a good definition of compositional.
TBL: but XML fragments don't have values
HT: I'm drawing an analogy to the application semantics of the subtree.
DC: Critically, it's all dependent on the media types. If these same constructs appear in an XSLT document, then the semantics change.
HT: Yes, XSL is known to commit tag abuse.
DC: Right, but therefore these tags have compositional semantics at best in certain particular vocabularies, not in XML in general.
HT: Consider an xhmtl:input element in the middle of an XML Schema. Should it have its compositional semantics in that context.
TBL: We're trying to have here a discussion of XML semantics, when XML doesn't have a semantic which is "thick enough" (did scribe get that right?) to grasp.
DC: Did you change your mind? Your design issues article seems to take a different position.
TBL: I think Henry is going too far in looking for compositional semantics in XML. With RDF you're on firmer ground, because we have a clean notion of the "value" which is the RDF graph. We can thus discuss rigorously which syntactic constructs are equivalent. HTML and SVG have presentation. For example they define screen real-estate. We might ask which things produce the same pixels. Talking in general about XML without knowing the namespace or application doesn't work well, because there's no common sense of meaning. Thus it's hard to talk about compositional semantics.
<Zakim> raman, you wanted to add, xml-edit raised similar questions, since now you had to distinguish between "displaying" vs "editting" and to add, semantics are also a function of what
<DanC> I hear timbl saying "xml documents have compositional semantics" in http://www.w3.org/DesignIssues/XML and "xml documents do not have a compositional semantics" on this call
TR: The interpretation of something like HTML+SVG can depend on how you're using it, e.g. for editing vs. presentation.
<Zakim> DanC, you wanted to observe that it seems to be an academic, untestable question as to whether xml:base is part of the xml abstract syntax
TR: I don't think you can answer this question in the abstract. What you do with it, even if it's a specific vocabulary, matters a lot.
<Zakim> noah, you wanted to discuss variable processing of same doc
DC: There's no way to test whether XML base has an effect on the processing. You can't in general tell where all the relative URIs are
<scribe> scribenick: ht
NM: Close to TR's point -- consider XInclude in particular
<timbl> Noah: I think this is close to building on what Raman said. For xinclude in particulr, it i temptingto take a view that either the pre- or post-include document is somehow more fundamental.
<DanC> (might be nice to have a structured argument editor that we can all twiddle at.)
NM: It's tempting to presume that the pre- or, more likely, post-include infoset is the true interp of the document
<timbl> NM: I take the view that they are both just as fundemental.
NM: But I think it can be either
... Consider the C preprocessor
<timbl> Suchs for a C preprocessor, is the pre- or post- include version most signifiant? Normally compilers try to work with the line numbers of of the source even though they compiled the include version.
NM: A good debugger will allow you to work with the _un_preprocessed document, even though the compiler has really worked on the post-processed version
<timbl> With XML base, XMLinclude, etc you may want to liook at teh document before or after these forms of processing.
NM: Or consider DSig -- I may want to sign the xinclude elt itself
<timbl> To me, the infoset which has been digitally signed has great meaning. Other rimes, I am only interested in teh expanded meaning.
NM: or I may want to sign the fully expanded doc't, and expect you to check against the expanded doct
<timbl> -- NM
NM: I think we'll have a better story if we have a story that can deal with both levels
<Zakim> ht, you wanted to point out that the message _asks_ whether it should be a Best Practice for applications to _define_ a comp. sem.
<noah> scribenick: noah
NM: right, I said that both the unprocessed XInclude and the infoset resulting from processing are of significance and can be used in specifications. To be clear, I'm not saying that no form is special. I'm saying that forms become special because the specifications for them say so.
HT: It's about mapping compositionally onto your domain semantics.
<DanC> timbl, if you disagree with what HT's saying, I'll be perfuddled, w.r.t. [[ Paul opines, Top-down self-descriptiveness is one of the major advantages of XML and I think that doing otherwise should be deprecated. I completely agree with this conclusion. ]] -- http://www.w3.org/DesignIssues/XML
HT: In any given application context, it's a good thing if the mapping from your Infoset to your application domain is compositional.
<Zakim> timbl, you wanted to disagree with Raman and NM about there being being no special form.
<ht> [NM, backing up]: It's up to the application context to decide what pre-processing gets done
TBL: There are lots of times you do things like view source, editing, etc., but I think that for an SVG document the semantics of "the circle" are fundamental.
TR: I agree with you. But we hit this when we tried to build an editor in the XForms context.
<ht> TBL: XInclude has level-crossing capability
TBL: this reminds me of the discussion of XInclude, where we asked to include a target (svg:circle) as text plain. You do have the ability to do level breaking in XML.
TR: it's eval vs. quote
VQ: suggest we end discussion for now
TBL: how much are we popping off the agenda stack?
<DanC> (I need a story in which to set this conversation. Something where interaction between, say, xinclude and xml signature matter.)
HT: I covered everything I put in the message, this has been helpful.
<ht> HST agrees that eval and quote are a) fundamental and b) not immediately covered by the simple functional language analogy/compositionality story
<DanC> (I take it "NW with help from HT, produce a draft finding on XML functions" continues)
<Vincent> DanC, yes this action continues
VQ: Last time we discussed this, we had hints that the Schema WG might have done something.
HT: The schema WG has indeed made progress on this. Some good chance their work will be public soon. Let's discuss then.
<ht> ACTION: HST to bring us back to xml11Names-46 after the XML Schema WG publishes its expected Last Call PWD [recorded in http://www.w3.org/2006/02/07-tagmem-irc]
VQ: there was a message from Dan at http://lists.w3.org/Archives/Member/tag/2006Jan/0011.html
DC: WSDL WG had in their charter to produce
WSDL mapping to RDF.
... I am trying to figure out whether there are any of the semantic web
services build on this. So far looks like not.
<raman> off to next thing ...
DC: I'm probably late here. The charter in question has gone out for review.
TBL: We've tended to ask for RDF mappings. Risks that the WS community lacks some combination of the necessary knowledge or perhaps motivation to do it. We wind up with things like WS metada on the semantic web side being unfortunately disconnected from, e.g. WSDL constructs. The question is ultimately whether to try harder to get these communities together. Does the TAG see this as a problem?
<Ed> I see this as a problem.. that should be addressed.
VQ: Question is what is the role of the TAG in trying to get these communities together?
ER: Yes, I see overlap.
<Zakim> noah, you wanted to talk about motivation
<scribe> scribenick: ht
NM: The elephant in the room is the lack of feeling on the part of the Web Services community that investing in these things will bring compelling value. Convincing the Web Services side that there's value here is that hard part, once they're convinced of that, in particular that there's commercial value, then the convergence will not require artificial push from us. Just saying "You should want to do this" won't make it happen, much better to show them where real value will arise. Compare the SOAP GET stuff -- we 'persuaded' them to put it in the REC, but they weren't convinced of the value, so few have implemented it.
<Zakim> timbl, you wanted to play devil's advocate
<noah> scribenick: noah
NM: I think we'll do better to convince people how they're going to get value.
TBL: That value isn't going to be there if we just do WSDL & RDF. If they do a large chunk of their enterprise data then the WSDL mappings may show their value.
<DanC> +1 feedback loop is critical; there's not sense doing standards work without it
NM: Right, but companies like mine don't do WSDL in isolation. If our enterprise database customers are convinced that WSDL/RDF mappings bring value, we'll be glad to motivate our WSDL people to do it. The challenge is to make those connections.
TBL: Did our charter for RDF DAW encourage or discourage service description?
<DanC> serviceDescription issue in the RDF Data Access WG
<DanC> postponed
TBL: If this were OWL-complete or RDFS-complete, it would be sort of crazy if you couldn't then connect to the WSDL
DC: I found a big long URI that the WSDL group was giving for a SPARQL interface.
TBL: 404?
DC: No, or we wouldn't have let them publish, but I'm not sure what you get.
<DanC> [[
<DanC> postponed 2005-05-19:
<DanC> whereas the serviceDescription designs aren't maturing in the timescale of the current schedule, and implementation experience is somewhat thin, RESOLVED to postpone serviceDescriptions
<DanC> ]]
TBL: who's going to hurt if this problem isn't solved?
ER: You'll get more trouble down the line with divergent answers.
TBL: Well, you're going to have for each thing that comes out a retrofitted gadget to get RDF out of it. It's tempting to tell people to stop making legacy systems, but on the other hand that's not useful, because legacy systems have been produced for years, and will continue to be. There's a certain pace and timing to these things.
+1 exactly. We have to engage the market in a way that fits with the pace(s) that it can reasonably handle
ER: Are they just not focussed on this?
TBL: Lots of current work is focussed very much on top down design and information hiding, modular classes, etc. Web Services let's them do this on a larger scale, or maybe even between enterprise. It still tends to be object to object.
(Noah is not so convinced, I think there's also a lot of business messaging a la lightweight EDI)
TBL: RDF gets you benefit when you break that mindset. It still feels object-like.
NM: I think things are heading to be more document-like. I'll send you a purchase order, you confirm that I've purchased the stuff. No public objects there.
TBL: We're starting to declare things like invoices that can be shared by services. That's closer to semantic web. So you're moving closer to the semantic web, though with the possibility that you're reinventing it. Maybe the invoice should be an RDF graph.
ER: versioning
TBL: At least in RDF, the parts of the graph are separate.
NM: The whole point in Web services was to NOT do what Corba and COM did, I.e. to not require agreement on object models or programming models at the two ends of a wire.
TBL: if I've invoiced you and specified at as high a level as possible the semantics of the message then I have maximal flexibility
<timbl> I agree that GRDDL is a very important part of the dsicussion.
NM: Right. The problem, as I think Tim and I discussed years ago, is that XML and RDF wind up in the same space. Triples all the way down makes sense, XML trees are working moderately well. We've got to deal with the overlap.
<timbl> Of course GRDDL needs a mapping, so it puts RDF mapping back onto the agenda.
<ht> HST has sent email about his concerns with the PLP draft -- NM, please take note
NM: Perhaps GRDDL might be a good example of a way to get RDF out of SOAP messages.
VQ: We agree to defer until next week the three issues Dan asked us to discuss: (1) /TR/ heartbeat, (2) namespaceDocument-8, (3) xmlVersioning-41.
DC: not urgent if we don't do it even then.
TBL: Thank you to Vincent for chairing.
<ht> Noah, it's the ones DanC asked to have added, plus PLP, I think
VQ: we're adjourned.