(Aim: Review Status and advance discussion).
(Aim: reach concencus/finding on 2 or 3 *big* ones)
Issues (in no particular order):
All TAG members were present.
See also: photo.
SW: We probably need to get the writing assignments integrated then we can take on more responsibility again
TB: We either need to get more of Ian's time or find another resource. And we need to decide this soon.
PC: Negotiate with the AB to push the current process document out so that we can get more of Ian's time
TB: What are our timing constraints?
PC: We should try to get something out by the beginning of the summer
DO: Issue 7 has really taken a lot of time because it
DO: is important. We need to finish that up.
TBL: hopefully after we get the arch. document done, we'll be able to do findings when we find points of contention
ACTION: TBL to discuss the negotiation of Ian's time with the AB
For telcon agendas, we'll focus on one or two issues (b/i on the agenda)
Some discussion of moving the telcon time; delayed until Chris arrives
PC: It would help if the agenda or the person arranging the meeting could give explicit pointers to new threads that are going to be discussed
Proposal: move the telcon to Monday, 15:00 eastern
RESOLVED.
We'll stick with simple prioritisation to maintain common focus (Issues list/b/i from the agenda)
TBL: what happens if the TAG reaches a finding but isn't really done because we need to coordinate with some other group
TBL: somewhere we should keep a list of contentious laison issues
PC: we can't assume that the quarterly IETF/W3C meetings are the target points for getting work done
TB: what we really should do is probably what CL and I did: join the mailing list and contribute a few messages
RF: we can't learn new information from the IESG because they're not looking at brand new issues
PC: so we should always clearly identify who the other parties are when we have a liason issue
TB: the take-away is that by default we should try to deal with liason issues at a grass-roots, peer-to-peer level. And if that doesn't work, it's not clear what to do.
TBL: but we should catalog it so that we can answer the question when it's asked
SW: have we had any feedback from the AC/AB about our reports? And CL pointed to an article about the TAG
PC: we should wave the flag more when the architecture document is ready for review
CL: we should do a press release when we publish the first architecture document
General consensus is that the signal to noise ratio has gotten better
[[[Break]]]
TBray takes over scribing at 11 AM.
Move to issues, push Architecture-doc issues to later.
DO: I posted yesterday a draft of a proposal for a GET binding for some HTTP POST binding.
Proposal: TAG should do the work, not current XMLP WG.
TBray: Reasons are political; XMLP is tired and wants to get their doc out; WS Arch group could take it on but that would stretch way out into the future. So I agree TAG should do it.
TBL: Is there a risk of infringing on other WG's jurisdiction and causing bad feelings?
DO: In general yes, but in this case the relevant WG is feeling closed to finished and is tired and would probably welcome TAG intervention.
DC: Does this mean we agree that GET should be used?
TB: Even if you only thinik a small proportion of WS is amenable to get, the cost is low so why not do it?
RF: Danger of putting the wrong information while encoding method calls in URI. So maybe the service should have the responsibility of publishing a GET-able URI for the info it makes available. If it's important content, then it has an identifier.
CL: Process issue; danger of interference. Scenarios where we intervene arbitrarily is different from that where there's a desire for help from the WG. Danger of groups in trouble appealing to the TAG for rescue.
PC: Current binding HTTP SOAP binding is POST only. Are you proposing an alternative mapping?
DO: An additional mapping.
PC: So if this were being done by XMLP, it would be in part 2 of SOAP, bindings? (Yes) Why is it important not to disturb the current SOAP process? Is the real reason that they're tired or they just want to get 1.2 done and more to other things? So is this just an alternative? In which case we could do a NOTE. Or is this something that really should be normatively in SOAP? If so, it might be a real mistake for us to do it.
TBL: Current SOAP spec says there are several bindings, of which they provide one, via POST.
PC: Is this effectively a third binding?
SW: What's in the space now: We've established a framework for bindings, describing message exchange patterns, bindings say they support particular patterns. This could be a new binding with new patterns.
DO: Thinking more that this would support existing request/response pattern. And in fact it must be mechanically transformable.
TBray: Not only in principle transformable, but in practice not difficult.
DC: SOAP 1.2 should say that use of GET is desirable, and perhaps have a pointer to a NOTE by Orchard et al. Also I redrafted my finding.
DO: I talked to David Fallside, who seemed to welcome our work in this area.
[TAG walked through most recent Connolly draft, general approval] $Revision: 1.19 $ of $Date: 2002/07/16 16:12:48 $
DO: Note that XForms will also have to URLencode its stuff; this should be consistent with SOAP URLencoding.
CL: Horrible problem with character encoding in URL-encoded or message body, XML message body makes it go away, but loses advantages of GET.
RF: Partial solution is a hidden form field saying which charset; but that doesn't solve 100% of problem.
TBray: General solution as in IRI and XML 1.0 spec; always use UTF-8 along with %-encoding.
RF: Problem is, browsers don't do that.
CL: Problem with big URIs; take a UTF-16 Chinese text, put it in UTF-8 and %-encode and you're going to hit 4K chars in your URI pretty darn quick. Doesn't want %-encoding to become the normal way to ship XML around the Net.
PC: People jave tools to build WS; default should not be POST.
DC: Yes, it has to be POST, because the web service might not be SAFE.
CL: ACTION to add a concern re non-western characters in this scenario.
RESOLVED by consensus to add another bullet to the top of the doc saying GET should be used for safe/idemportent operations.
DC ACTION to write up limitations in draft in re SOAP.
ACTION TBray & DC & CL to polish up DO's 0.1-level draft & find out what's going on with XForms.
ACTION DC add pointer to PROPfind to limitiations/problems section.
DC/TBL: Should we think about adding a QUERY method, or send a body with GET?
RF: HTTP already allows that... but you lose the advantages of a small URI. DC action item to summarize history, given that the QUERY idea has come up more than once previously; outline all 4 corners of the design space.
ACTION DC to republish. RESOLVED: default is that it gets adopted as a finding.
DC action item to point out that WSDL should take this into account & also SOAP primer.
Discussion on process: TBL & PC point out that this has an obvious place in the work of and the spec produced by XMLP, and it seems wrong to take this out of their hands.
TBray: I want this out in the 1.2 timeframe, so let's do it in parallel.
DO: Options: - force it into SOAP 1.2 - let it into SOAP 1.3 - do it parallel e.g. in the TAG His preference is not to force it into 1.2.
PC is not comfortable with the TAG trying to take this on in parallel with the endgame on SOAP 1.2.
DO, PC, TBray: Strong desire not to slow down SOAP 1.2.
Straw poll on: Make it a requirement for SOAP 1.2, or allow solution at a later date:
CL: Later OK
DO: Later OK
SW: Either way
PC: Later OK
TBL: Abstain
DC: preference for Now, but both acceptable
NW: Worried about consequences of letting through, but don't want to hold it up.
TB: Like Norm
RF: Later OK if we can get a NOTE in front and institute work item immediately. Brief discussion of DO's draft.
RF: Rather than construct URI equiv to SOAP structure, why not put that in the WSDL or other higher-level spec.
TBray: because arch is layered and SOAP has to stand on its own.
DO: Explanation of difference between RPC and doc-literal style of output.
TBL: TAG's desires are clear: we want our last call issue to result in this capability going into 1.2 at the current time. On the other hand, this is tough managerially and people like David Fallside need to brought into the loop. We get things like this all the time, where there's pressure to get a spec out but also pressure to cover an important missing point.
PROPOSAL: The TAG finds that the absence of a GET binding in SOAP is incompatible with the architecture of the Web, in that it contravenes the architectural principle that important information resources should have URIs.
break for lunch.
Minutes of TAG F2F meeting taken after lunch and beach walk by Paul Cotton. The proposal on the table just before lunch was the following:
Proposal: The TAG finds that the absence of a GET binding in SOAP is incompatible with the architecture of the Web, in that it contravenes the architectural principle that important information resources should have URIs.
TB: Even if get concensus on this proposal we may want to discuss our intent with the XML Protocol WG members and chair.
CL: How much lag do you want?
TBL: Any objection?
PC: Paul abstains unless we make clear what we want to say offline.
TB: What about adding a para that states: "The TAG appreciates the urgency in completing the SOAP 1.2 specifications and wants to work with those concerned to address this problem with the least disruption possible." There was no objection to the proposal as amended.
RESOLVED.The TAG finds that the absence of a GET binding in SOAP is incompatible with the architecture of the Web, in that it contravenes the architectural principle that important information resources should have URIs. The TAG appreciates the urgency in completing the SOAP 1.2 specifications and wants to work with those concerned to address this problem with the least disruption possible.
ACTION to DC to send a message to the XML Protocol comments list to point to this resolution.
Next issue from agenda:
"It seems to be that the RDFCore and XML Schema WGs (at the very least) ought to develop a common, reasonably acceptable convention as to the mapping betweeen QNames and URIs. Perhaps this is an issue that the TAG ought to consider (because it is a really basic architectural issue)."
DC: XML Schema produced URIRefs for each of the XML Schema primitive types. Dan used an example to indicate how to use the QName "decimal" along with the Namespace for the XML Schema types. But it is not necessarily possible to concatenate the QName to the specified Namespace to create a URI.
TBL: This was done as per the original Cambridge Communique.
TB: Confirmed that RDF requires or at least wants that you can concatenate something in a namespace (e.g. the QName) to the Namespace URI itself.
DC: The XML Schema spec does not map this pair of names into URI space. The TAG might want to support my view that this should be added to the XML Schema 1.x or 2.0 Requirements.
PC: Why did Schema do this?
DC: Since it is possible to have multiple things in an XML Schema with the same name and mapping to the URI space could cause a conflict.
PC: Do we really have an issue we understand here?
TB: I agree but the issue may be here that RDF and others are having troubles importing data types from XML Schema. These people need a good way to "point into XML Schema".
DC: Maybe the TAG could simply support the comment.
RF: Maybe we should consider the issue of RDF doing concatentation to produce URIs.
TB: The way RDF uses namespaces is obviously different from the way others use Namespaces.
RF: Some implementations strip trailing "#" and this might also be a problem.
TB: We should agree that however we resolve this the resulting URIs need to be unique.
DC: It sounds like the TAG does not understand this problem well enough to support the referenced comment above. But if it does then maybe it can support the above comment.
PC: Is the problem the lack of mapping XML Schema types to URIs or is it just a manifestation of what many WGs are doing today. For example the XML Query Functions and Operators Namespace does not provide a URI for each of the functions since it does not define how to concatenate the function names and the Namespace URI.
TB: Everyone would agree that items in an XML Namespace should be named but do we have agreement that they should be used in combination to produce a dereferenceable item.
TBL: Either we attack this problem as a series of special cases or should we attack the problem by re-examining the original premise in the Namespaces 1.0 specification.
TB: This is an ugly piece of work but it would be an architecture bonus. In addition you have to choose whether to produce the URI via concatentation as done by RDF or by using some other technique.
CL: We should be able to define any algorithm for the creation the URI e.g. concatentation is not the only possibility.
TB: If you give a universal rule for turning a Qname into a URI then we need to have an answer right up front as to whether they are de-referencable.
RF: Notet that the way you choose a Namespace URI will actually impact the algorithm you choose to combine the QName with the Namespace URI to produce a URI. You may want the Namespace URI to end in a "/" to make the concatenation to work.
DO: TB, is this coupled to the discussion to the Namespace document issue?
TB: Yes. TBL and DC: Both stated that having a document at the end of a Namespace URI is a good idea.
TBL: The construction technique may also require you be able to break the constructed URI apart to get back the original Namespace name and the QName.
CL: Since the W3C Pubrules required IDs on every referenceable part of the spec and that is probably is a reasonable place to point since it actually is a human readable description of the item being described.
Break at 3:04pm.
(discussion on rest of agenda)
TBL: Who to pass this resolution to - XML Core?
TB: Suppose we did concat. Support we decided ns docs were RIDDL-with-RDF. Suppose we had a standardized vocab. Then you could deterministicly take the concated URI and find what you needed.
CL: deterministically meaning a computer can do it
TB: yes
PC: So what types of information about a function would you want?
TB: RIDDL purpose=humann readable documentation for example. Notice that this *does* require tuples .... Not worth doin wname to URI mapping unless we go the whole hog and say how to get the real info.
DC: They are seperable, but the world does not want a seperable solution People want all the parts.
PC: Many people happily using spec as is and not requiring dereferencability. Concern over backwards compatability.
PC: So do we write this or assign it to a WG
TB: The mechanism to use those URIs is a big item so we should find out what the priority is on this work
CL: Briefing pacjage, or existing WG?
DC: Depends o resource needs
NW: Its a big chunk of work
TBL, TB: RDF is a big chunk of the solution
PC: Or that the only reason we need it is because RDF did it already
DO: So is this important to RDF specifically of Web in general
PC: Not clear
TB: History shows that , to the extent you tie stuff into URI space, you win in general
PC: Problem with existing non-dereferencable namespaces. Need to show a clear benefit for existing customers.
TB: Automatically discoverable stuff lowers support costs
PC: Concern that offline working continues to work TBL: Example of GUIDs, either works or it says its broken. URI reference table will be a central part of design; if online you can get extra information. Well known namespaces burned in, no need to dereference.
CL: Clarification - so you don't always need to dereferece a ns uri it might be cached, or compiled in, etc
TL, PC: Yes (exanmple of precompiled schemas in SOAP)
DC: Problems when ns info changes
PC: Very much so (examples)
CL: So namespaces never change once published?
TB: Can't generalize
PC: Acceptability is based on showing benefits outweigh costs
TB: Take this to AC, see if they think it is important
DO: Can't just do that, need mor einfo for AC to make informed votes. Needs a strawman proposal.
SW: Not clear anyone but RDF needs this
DC: Feedback shows the disconnect betwen RDF and other stuff has a cost.
TB: Existing code works. Problem is the expectation of dereferencability will be generated.
PC: Pubrules cost to even getting the human readable ns doc published. More work to get the additional data in the uprated ns doc. Its a higher bar, and needs to have a clear benefit.
TBL: So cost is deployment of ns docs. Expect that there would be an API to find what is known about a given ns API.
TBL: Same for GUID currently
DC: No - have to know what it is first, if its a class etc.
PC: Should get a discussion started on www-tag, before putting this to AC
ACTION: TB get such discussion started
RF: Not clear we need to solve both parts at one. Value in getting the first part done - how to compose the URI
TB: At technical level i agree with Roy; having been beaten up over fuzziness of ns dereferencing, don't want to go there again.
NW; Agree there is value in just the first part, we are fairly sure we know what a solution looks like, tat we understand the prolem. Not so clear for the second part. TBM: TAG can say there must be an algo for making a URI from a tuple. Decoupling seems important architecturally
TB: Already said its desirable to be dereferencable.
RF: Only get full benefit when dereferencable. Value to make future-proof uris.
TB: Agree the can be de=coupled, but you will get shot and accused of sloppiness if you don't do the whole thing.
DO: Is community more used to partial solutions? (assorted surfing analogies.....)
TB: Developers see no problem, its the theologians
RF: Or folks like RDF that are doing different things than originally envisaged they would be used for.
TBL: (example of dereferencing what a footnote element means in a MS namespace)
TB: One of the questions to take to www-tag should be usefulness of doing a partial solution.
============ issue not closed ======
TBL: (summarises previous discussion, top-down namespace meaning )
DO: So this is a document and not a message? Reference to media type
TBL: clarifies this is application/xml and */*+xml
TB: We are talking aboit resource representations, without additional metadata
DO: So this applies to application/soap?
TBL: yes RF: What is the issue, exactly?
TBL: Can't know the meaning of any innter namespace unless we know the outer layers.
NW: Studies this and came to the opposite conclusion to TimbBL
DC Want a test case to try against yout two designs.
NW There is always an outer layer of context.
TB: xml:lang is an example, not dependent on anything at all in terms of context.
TBL: Counter-example: tim-rot-13 namesoace
CL: More realistically, xml encryption. (rathole on realism or lack therof of examples)
TBL: XSL-T transform inside an XML Query example, something like that TBL: (draws on whiteboard)
<foo xsl:version="blah"> ... <xslt:whatever> .. </xslt:whatever> <xmlenc:> </xmlenc> ... </foo>
NW: add xsl:version attribute on root, or example does not work (added above)
TB: media type is high, first off. So if this says its xsl, then process it as xsl, etc. Thus, never ever use application/xml
TB: Secondly, architecturally unsound to make proc decisions ased on ns of elements without regard to ns of enclosing elements and mime type.
TBL: describes a pipeline where each stage produces a different mime type, then says that it does not scale, and sucks. Top-down, xml function based on namespaces and ignoring mime type, recursive descent, is better
RF: Three broken specs, that did not define their root element.
NW: (adds an Xpath for the third following sibling, so walks out of the subtree)
PC: You said that you can't do anything without the ns of its encclosing element. Its an NxN problem.
TB: Top level heading is done on http headers. If served as html, send to html processor,etc. Correct way to deal with enclosed namespaces varies by application. So in practical terms, are you wantin ti require any s/w be prepared to do arbitrary dispatching to other modules based on ns?
TBL: Not constraining software, but want to have the defined output document to a series of recursively explanded functions Can do lots of ways as long as you get the correct result.
TB What sj=hould the software do?
TBL: Not wanting to say what S/w should do, just what the result is.
DC: So definitions of ns should say what to do with unknown ns.
NW: Points to pipeline language submission
TBL: Its another function.
DO: So in case of application/xml, this dispatching is what you do. Other mime tpes get to make their own definitions.
CL: The special case of dispatching on an attribute, not on a ns, was not covered. Oh and btw this example is never served as *the content*, but as a stylesheet linked from the content
RF: Mime is not layered, this is a problem. Need to store the layering of twhat the outer types were.
TB: Seeing that pipeline efficiencies can be gained from the functional model. Could avoid a series of batch processes.
TBL: References should always be to the final tree. Mutally recursive would blow up ;-)
RF: Leads to much need for escaping elements. Don't do multiple layers in XML.
DO: XML enc makes it explicit how it does the layering. Sepc should also say how it does layering of itself.
TB: attribute is redundant - it only makes a difference if it has already been sent to an xsl processor.
NW: Worried I can't write the 'count the tags' processor because the xsl-t always gets expanded
TBL: Social contract of the Web @@@ scribe did not follow@@
DC: Example of recipeML that I just made up, plus a PU to some CSS
CL: Plus eXLink
DC: Not yet, lets do the simple case first (no resolution really)
DO: So what is the actual problem? I have to create my own media types and processing model for anything to work. Lowers the bar for general xml processors
DC: No, raises it
TB: Lowers the bar for language designers
DO: yes. So what is te brief problem summaty? We can't make generalised processors because we don't know how to mix namespaces in the general case.
PC: how this links to xml processing workshop results
TBL: PC: Processing language is fines, since I can choose not to use it. But clearly there is no default processing model, ws was clear it did not want one. No one size that fits all.This is an attempt to make a default processing model.
DO: Default processing model for application/xml only?
TB No, all xml DO: So application/soap is ok wheras application/soap+xml would give me this model.
TBL: Yes.
TB Media regirstation gets to say what its processing model is
TBL: media type registration cannot define elements that redefine meaning of parents or siblings.
DO: So per-spec processing models could be done
TBL: Its too complex
DO: Paul, why do you object? A vocabulary can still ignore the processing model. TAG needs to ensure it does not create new problems
SW: RDF saw this problem, its not well defined
TBL: XInclude and XEnc for example, can you nest one inside the other? Tools don't do it, its not defined.
TBL: Hacked versions with explicit processing based on makefiles work.
PC: So if you were voting on doing a processing language, you would vote no?
TBL: Correct, it should be a simple processing model.
PC: Composability is very important.
RF: XML should be a fully self descriptive language, but it isn't, yet. An element needs to be able to say, process me first
CL: That doesn't scale.
SW: Closing remarks?
PC: Need to seek direction from AC on direction of XML activity.
ACTION DC: Edit raw minutes to nice HTML public minutes.
DC: Proposes SW as co-chair of TAG So RESOLVED
Next f2f meetings
24-25 Sept in Vancouver
18 November, Boston (twinned with next AC meeting)
(regrets RF, ApacheCon)
SW: Offers to host in Bristol
PC: Next should be at tech plen, Mar 3-7 2003 in Boston, those with 1 year terms will not be there
based on:
DanC, Norm W, Tim Bray, Paul C, and Chris L, scribes, for TimBL and Stu,
co-chairs
$Revision: 1.19 $ of $Date: 2002/07/16 16:12:48 $ by $Author: connolly $
