W3C | TAG | Previous: 28 Apr teleconference | Next: 12 May 2003 teleconf

Minutes of 5 May 2003 TAG teleconference

Nearby: IRC log |Teleconference details · issues list · www-tag archive

1. Administrative

  1. Roll call: NW (Chair), RF, DC, DO, CL, IJ (Scribe). Regrets: SW, PC, TBL, TB
  2. Accepted 28 Apr teleconference minutes
  3. Accepted this agenda
  4. Next meeting: 12 May with Voice Browser WG. Possible regrets: DO.

1.1 Meeting planning

1.2 W3C Track Presentation

1.3 TAG report at AC meeting

  1. Suggestions for TAG presentation at May AC Meeting from DO and PC
  2. Action DO, CL: Present TAG's AC meeting report to TAG. Due 5 May

    [To be discussed 12 May]

2. Technical

  1. whenToUseGet-7
  2. contentTypeOverride-24
  3. uriMediaType-9
  4. abstractComponentRefs-37
  5. Architecture Document

2.1 whenToUseGet-7

IJ: I propose to accept DC's proposed simplifications (talk about "read"/"write") and put out for review.

Resolved: IJ can publish get7 finding with DC's suggestions.

Action IJ: Publish revised get7 finding with modifications.

2.2 contentTypeOverride-24

Action IJ: Send email to the Voice Browser WG.

2.3 uriMediaType-9

[Ian]
DC: I propose to withdraw that action. Chris pointed out in email that looks like battle over.
[Chris]
nearly over
I gave specific feedback on how to complete it
[Ian]
DC: But in minutes of 13 March IETF/W3C teleconf, some relevant actions taken.
RF: I'm not sure that IETF finished the tasks that CL requested.
CL: It might be handy if the TAG confirmed my position.: I suggest the following changes
  1. The first column should be the subtype string, as now, and should always link to http://www.iana.org/assignments/media-types/typename/subtypename
  2. The second column should contain, as now, the name of the format, which is or should be provided for all types.
  3. The third column, which does not seem super necessary and could be omitted, would be a link to the person that registered that type or wrote the rfc that registered it or wrote the email that registered it or whatever. I don't see a lot of use for this, really.
RF: I don't think they would disagree; question of resources perhaps.
CL: We could also point out that these changes would address a lot of what DanC talks about in his internet draft.
RF: You could suggest changes to the RFC : How they should maintain their site.
DC: Next sync point for W3C/IETF is 17 June. I propose we withdraw my action and check in 17 June.
Resolved: DC's action withdrawn on this issue.
Action CL: Propose CL's three changes to registration process to Ned Freed. [What forum?]
DC: You can find out who's editor of MIME spec that talks about registration. You could write editors and cc public-ietf-w3c.
[Chris]
http://www.ietf.org/internet-drafts/draft-freed-mime-p4-00.txt
[Ian]
DC: I'll likely ping Ned on this (e.g., one week before) 17 June IETF/W3C meeting.
IJ: Sounds like we're not quite ready to move issue 9 from pending.
DC: Indeed.

2.4 abstractComponentRefs-37

[Ian]
DO: One issue from SW has to do with getting type info out of the URI. Question of "no metadata in URI". Little traffic (publicly or privately) expressing preference for various mechanisms.
CL: I commented on syntax ; use of xpointer.
DO: I understand that there's some question about whether it's a desirable requirement that the type info be in the URI.
CL: Example in schema: "#" followed by "float".
RF: If you're dealing with polymorphic operators where function distinguished by type, then you would need something.
[Zakim]
DanC, you wanted to respond to opacity and constraints
[Ian]
DC: Opacity has to do with freedom of choosing URIs.
[Chris]
eg http://www.w3.org/2001/XMLSchema#float.minExclusive
[Ian]
DC: E.g., if you require first path component to be WSDL type, then you restrict what server manager can do. If you are making up URIs, then you can say "this part of it is the type"
[DanC]
haven't we agreed that things that have #'s in them are URIs too?
[Ian]
NW, CL: See also TB email on Apple Music Store and use of URI schemes instead of headers
DC: We don't have much good motivation for not making new URI schemes. Apple folks did it and people seem to be happy. Which of DO's options is likely to bite me if I ignore it? Has the WSDL WG picked one?
DO: They picked the one they suggested - namespace + fragid : 8. Use namespace name and new fragment identifier syntax.
[Ian]
DC: I don't hate option 8 all that much.
The sample URI is
"http://airline.wsdl/ticketagent/#input(TicketAgent/listFlights/listFlightsRequest)".
RF: Hash marks are usually left to people who have no choice, not for designers of the media type.
DC: I don't agree that this is a "violation of URI fragment identifier rules that fragment identifiers are based upon the media type of the dereferenced content."
DO: If somebody puts a RDDL doc instead of a WSDL doc, the URI producer will have to use a different URI, depending on the media type.
DC: The answer then is don't put a RDDL document there. You can use this syntax and be consistent with the URI spec; but you can't have all your cakes and eat all of them (i.e., can't also be able to put a RDDL doc with this same syntax).
NW: If you are relying on use of a frag id, then you'd better expect to get back a RDDL doc.
[DanC]
all roads lead to issue 8. there is no other issue 1/2 ;-)
[Ian]
DO: The consequence is tight coupling between URI syntax and WSDL doc.
[Chris]
so, we need a sort of double dereference - from a namespace to a (part of) a rddl document to whatever that part points to///
[Ian]
DO: If you don't use fragids, you might have other probs but not this particular one.
[DanC]
hmm... http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest
[Ian]
RF: Slash characters can't be used for something other than hierarchy.
[Discussion of option 10]
[DanC]
option 10 (http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest) is inconsistent with timbl's position on issue 14, which I sympathize with
[Ian]
RF: Use of parens is problematic (e.g., if relative URIs used within 2 ref items).
DC: TBL's position on issue 14 is that if you want to refer to a non-doc thing, you need to have a "#" in the URI.
[DaveO]
Roy, I think you are saying you'd change "http://airline.wsdl/ticketagent/input(TicketAgent/listFlights/listFlightsRe
quest)"
to "http://airline.wsdl/ticketagent/input/TicketAgent/listFlights/listFlightsRequest" or
"http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest/input"
[Ian]
DC: It's antisocial to constrain Web site managers to use URIs in a particular way in order to use your format. Don't tell me, e.g., that I have to put all WSDL files at the server root.
NW: The proposal would said that the WSDL doc could go anywhere on the server, but the "/input...." is controlled by the WSDL spec; not really "on your web server"; these are parameters to the service.
[Some agreement from DO, DC, NW that that's reasonable]
NW: Is it reasonable to say that wsdl docs and expected interactions are something server manager would be controlling, not just any user.
zakim, who's here?
IJ: In option 11, what is problem of "no hierarchy of names": Can't that be captured in another parameter?
[Norm]
You could have ...ticketagent?service=/TicketAgent/listFlights/listFlightsRequest
[Ian]
DO: One advantage of putting in a query string is that you can use relative URIs.
CL: If I have a namespace, doesn't necessarily mean that everything "below" a piece of path is co-opted by the namespace. However, with the proposed URIs of option 10, that part of the path is co-opted.
DC: The same is true with RDF when used with namespaces. Doesn't blow away space, but allows short local names. There's an issue on our list about making URI from local name and namespace name.
(Issue 6)
[DanC]
cf rdfmsQnameUriMapping-6 : Algorithm for creating a URI from a QName? http://www.w3.org/2001/tag/ilist#rdfmsQnameUriMapping-6
[Chris]
Next steps?
drum up more feedback?
get evidence people have read it
[Ian]
DO: Need more input. Maybe straw poll, with deadline.
C: Some of these are just hard issues.. Some people have read some of the issues, even though we don't have consensus yet.
NW summarizing perceived state of affairs:
1) WSDL group ready to adopt option 8.
2) The TAG needs to register a comment/objection if the TAG doesn't think 8 is a good idea.
NW: Please be prepared (i.e., read proposals) for discussion (and I hope closure) at 26 May teleconf.
RF: Once I understand what the goal is, I should have a clearer position.
[Roy]
I do believe that balanced parens should be avoided

2.5 Architecture document

See also: findings.

  1. 26 Mar 2003 Working Draft of Arch Doc:
    1. Completed action DC 2003/02/06: Attempt a redrafting of 1st para under 2.2.4 of 6 Feb 2003 draft. See request from DanC to consider this subsumed based on 26 Mar 2003 Arch Doc text.
    2. Action DC 2003/01/27: write two pages on correct and incorrect application of REST to an actual web page design
    3. Action DO 2003/01/27: Please send writings regarding Web services to tag@w3.org. DO grants DC license to cut and paste and put into DC writing.
      DO: In progress. I hope that it will be published by late next week.
    4. Action DC 2003/03/17: : Write some text for interactions chapter of arch doc related to message passing, a dual of shared state.

[DanC]

IJ: 26Mar draft is now more than a month old...
[Chris]
ij has comments on arch doc from timbl, will incorporate comments
[DanC]
... I got comments from timbl and Graham Klyne; I responded, though some of them merit discussiong
[Chris]
ij recalls chris has text, chris not sure what this refers to
no momentum for new draft without new text
could incorporate draft findings, seems early though
not quiter at three month mark, but not ready for last call in june
[Ian]
IJ: What do people expect to generate for new text?
CL: I agree with IJ that once findings are reviewed/accepted, that putting conclusions in arch doc a good way to go.
[Chris]
adding conclusions from draft findings 9after some discussion) is good
[Ian]
DC: Suppose we tried being schedule driven rather than feature-driven: last call in June with what we've got? Can we wall off the parts where issues are not resolved?
CL: Let's go through issues list and try to gauge whether we expect to advance on these issues by the summer.
[Moving on to 2.3]
[Chris]
ie, which issues will make a summer 1.0 arch doc
[Ian]
xlinkScope-23?
[Chris]
nope
[Ian]
CL, NW: Probably not for arch doc 1.0.
NW: I think we can probably proceed without that done for 1.0.
DC: Where does that hurt?
CL: Not static, but lots of dependencies.
[Chris]
To what extent should URIs be used in W3C specifications
[Ian]
IRIEverywhere-27
[Chris]
URIEverywhere-38
[Ian]
CL proposes a new issue: URIEverywhere-38: " To what extent should URIs be used in W3C specifications?" I think that once this issue is closed, there will be some effects on IRIEverywhere-27.
CL: Goal is to separate (1) issues related to IRI spec (2) issues strictly tied to URIs.
DC: That's issue 15 - URIEquivalence.
CL: Related but not the same.
[Chris]
busy writing this up
[Ian]
NW: I'm uncomfortable with moving the arch doc forward without some sort of answer re: IRIs. But perhaps we coudl.
[Chris]
agree we should have something in this one for version 1.0
[Ian]
# URIEquivalence-15
DC: I hope we get this one nailed one for arch 1.0. I think nearly done.
NW: I think we can be optimistic that we can close this one soon.
DC: I think we need a test suite for URIs (e.g., for comparison).
[DC said this as URI CG co-chair]
[Chris]
agree that there should be testsuite for uris
[Ian]
DC: I don't have a mandate per the Activity Proposal to do a test suite for URIs, but I"m considering proposing that again.
RF: I think there may not be many volunteers for a test suite, but I think nobody would stop DC.
[Chris]
from forthcoming writeup: "A fairly small group of such identifiers can be included in specifications and in the associated test suite, with a great benefit to clarity. For example, see the cases listed at: http://www.w3.org/TR/xml-names11/#IRIComparison"
xmlIDSemantics-32 is now public, will announce right after the call
[Ian]
NW: XML Core WG is actively discussing how to deal with xml:id.
[Chris]
xml core is discussing how to deal with xml:id
[Ian]
Action NW: Point Core WG to CL finding once made public.
NW: I think we should plan a last call for June, with whatever we've got.

2.6 Issues that have associated action items

3. Other actions

Ian Jacobs for Norm Walsh and TimBL
Last modified: $Date: 2003/12/17 18:50:31 $