W3C | TAG | Previous: 17 Mar teleconference | Next: 31 Mar 2003 teleconf

Minutes of 24 Mar 2003 TAG teleconference

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

1. Administrative

  1. Roll call: SW (Chair), DC, TB, DO, PC, RF, NW, IJ. Regrets: TBL, CL
  2. Accepted 17 Feb telecon minutes
  3. Accepted this agenda?
  4. Next meeting: 31 March

1.1 Meeting planning

1.2 Mailing list management

2. Technical

  1. abstractComponentRefs-37
  2. Architecture Document
  3. URIEquivalence-15
  4. contentTypeOverride-24
  5. namespaceDocument-8

2.1 References to abstract components (abstractComponentRefs-37)

[DanC]
"SCUD", nee "NUN"
[Ian]
PC: Question as posed:
> Is it wise to use fragment IDs for identifying abstract components
> within a namespace, even though it is the most natural and convenient
> mechanism? Is there another mechanism that would be preferable?
PC: I believe that answer to this question would be germaine to the current XML Schema work on SCUDs.
[TBray]
SCUD really sucks as a label
[Ian]
DO: We talked about this in Hawaii. I explained that WSDL was going to use the namespace name for abstract pieces. I pointed out that if namespace names were to be used in this way, a number of outstanding questions, in particular double use of index.
DC: How is this different from issues 6/14/8? See my message "rdfmsQnameUriMapping-6 affects WSDL too"
PC: How do we make progress?
TB: I probably agree with DC that there's natural overlap with issue 6. I think we could subsume this under issue 6, and immediately talk about it. In particular, I think Jonathan is right - that the proposed approach is architecturally wrong.
[DanC]
(propose approach uses fragments/ #)
[Ian]
DC: I disagree with TB.
RF: Not sure that this is part of 6; 6 is about establishing an algorithm once you know the namespace. I agree it's related.
DO: I tend to think that this is a new issue. This is about the relationship between use of a namespace name and frag ids.
[DanC]
ok, well, that sounds like issue fragmentInXML-28 : Use of fragment identifiers in XML
[Ian]
DC: My position on issue 14 is that using anything other than a hash for something that's not a document would be wrong.
[RAT HOLE ALERT SOUNDS]
DO: This is close to 28. If we said that the WSDL id refers to the concrete thing as represented in a WSDL doc, then I'd agree that it's part of 28. But now it's abstract.
SW: New issue?
Yes: DO, NW, RF, PC, TB, SW
No: DC
[DaveO]
Name: Definition of abstract components with namespace names and frag ids.
[Ian]
Proposed: abstractComponents-37
[DanC]
'abstractComponent' is ok by me
[Ian]
Proposed: abstractComponentRefs-37
[DaveO]
+1
[Ian]
IJ: I will use DO's title. I expect to use JM's example and question for the issue.
DO: There are some subtleties. One thing you'll notice is that they are naming things. What they've done is say that names are context sensitive. E.g., an operation and interface could be the same names. So they came up with an algorithm. Some people in the WG said don't use name constract at all, use id and ensure that's unique. New frag id syntax which is WSDL-specific. Thought a lot about using alternative URI schemes (e.g., URNs): Ran into problem of using HTTP scheme but desire to use new frag id syntax.
[Roy]
please link in (http://lists.w3.org/Archives/Public/www-tag/2003Jan/0148.html)
to the issue
[Ian]
TB: I have a big problem with the actual example in JM's message. Seems deeply unsound to specify the use of a frag id unless you know what the media type of the representation will be. E.g., if you knew this was RDF, it would be easier to accept.
[Zakim]
DanC, you wanted to suggest that if there are different namespaces, give each of them a different name
[Ian]
DC: I like the way they've done it just fine. The general idiom is that the frag id is whatever it means when you look up the document. You might have three different MIME types where it means the same thing in all three.
RF: The notion that identifiers identify documents is false. You can't use hierarchical syntax within the identifiers. The idea that it's an abstract namespace is false.
[DanC]
("false"? I think you mean you disagree, Roy.)
[Roy]
False as in not real, no reflection of reality
[DanC]
sure, there's plenty reflection in reality.
[Ian]
RF: This is just basic names. No need to use a frag id in this case. This is just a namespace that's hierarchical. What you get back with GET is independent on allocation of names.
DO to TB and RF: So let's assume that what they've done is bogus. What should they be doing?
TB: I made suggestions:
  1. Specify what the media type is that you get when you dereference a WSDL namespace resource (removes ambiguity)
  2. Abandon frag syntax, go with straightforward hierarchical syntax.
TB: Nobody has said what you'll get back from a GET. The semantics of what comes after "#" is really different in practical terms.
[DanC]
clarifying what I said: the general idiom docName#doodadName means whatever doodadName means as used in docName
[Ian]
DO: Let's assume that we agree that RDDL-foo is a good thing. What's the intersection with this question?
TB: RDDL-foo will have a well-defined semantics for frag ids....
DO: Suppose they get back a RDDL-foo document; seems like there's a conflict between RDDL-foo frag syntax and WSDL identifier syntax. Imagine that I come up with a fragment that looks fine in WSDL but is also fine in the RDDL-foo document. E.g., "#message". What if this maps to an id in the RDDL-foo document?
TB: This is an xpath on the WSDL document, isn't it?
PC: Close. It's a sufficient path to identify the local named item.
TB: Seems like it's a frag id that "would like to be interpreted w.r.t. the WSDL document".
DO: What's the URI of the WSDL document? They'd like to use the namespace name; there may be N instances of a WSDL document.
[DanC]
yeah! put WSDL documents at their namespace name. self-describing web!
[Ian]
DO: The namespace name is the thing that binds them together; not the URI (which may point to something behind a firewall).
TB: Seems like abuse of URI + frags.
[Norm]
Dave's example that demonstrates the potential confusion that can arise when fragment identifiers are used as names where the media-type is unknown is exactly why I agree with Roy that these are just names and it really is architecturally problematic to use fragment identifiers as names.
[Ian]
NW: Using fragids as names is making me uncomfortable. I'd be happy if we all agreed that this was a problem.
DO: I think the WSDL WG would be fine with input from the TAG on this (either "fine" or "do this instead"). Not sufficient to just say "Wrong" with no counter-proposal.
DC: I think it's natural to combine port names with wsdl namespace names, look them up and find a wsdl document that tells you about the port.
[Zakim]
DanC, you wanted to say that confusion can be cured either by changing tech. solutions or by un-confusing people
[Ian]
[PC summarizes issues, requirements]
TB: I agree that this is a real problem; not sufficient for TAG to just say "no" and go away. Does WSDL have an IANA media type registration in progress?
PC: Don't know.
DO: I think they plan on registrating a WSDL media type.
TB: In RDDL discussions, idea had been floated once or twice that particular frag identifier semantics required: inclusion of pointers to other resources.
[DaveO]
namespace name#rddl piece (like WSDL)#WSDL frag id
[Ian]
TB: Suppose you have namespace N. N comes with an xml schema and a wsdl document. I would like to have a way to do what these guys are doing - to point at something in a wsdl document when all I have in my hand is the namespace URI.
[DanC]
(would be nice if ftf place names were included in http://www.w3.org/2001/tag/#about so I could search on "Hawaii")
[Ian]
TB: You'd like to point into a document, and then a second fragment that identifies something referenced from that point.
SW: Why is conventional hierarchical path a bad way to go?
[DanC]
discussion in Hawaii of issue 8 http://www.w3.org/2002/11/18-tag-summary#RDDL
[Roy]
In the CMS world, a compound hierarchical document is no different from a hierarchical directory system -- all names are hierarchies and the names are separated by "/" all the way down to the smallest atom of content. WSDL defines a compound document namespace rooted at its namespace URI. So, add a slash and define the hierarchy below the namespace URI according to WSDL.
[DanC]
CMS?
[Roy]
content management system
[TBray]
yes but Roy, how do you when you can do that?
[Roy]
how do you know?
[Ian]
PC: Xquery functions and operators document has a namespace, all functions assumed to be in that namespace. How do I identify one of the operators?
[TBray]
I mean, how do you know to define the hierarchy according to WSDL as opposed to some other framework?
[Norm]
With respect to what DanC said, the problem is that they aren't *names* if the meaning can change depending on what you actually happen to get back. Names and addresses aren't the same thing and fragids are part of an address. IMHO.
[Ian]
NW: We'd make better progress if we had a way to use names independent of fragments.
RF: I would replace the frag with the hierarchy under the WSDL syntax. They define a hierarchy. The namespace URI is a universal root. Can use a namespace hierarchy. The only time a frag should be used is when the client side of a situation is given the opportunity to adjust what the original identifier identified; that's not the case here.
[DaveO]
Should http://airline.wsdl/ticketagent/#message(listFlightsRequest)
become ticketagent/message/listFlightsRequest?
[Roy]
yes
[Norm]
http://airline.wsdl/? Do you mean http://example.org/airline.wsdl/?
[DanC]
this is *exactly* issue 14. How did anybody think it was otherwise?
[Ian]
What about ticketagent/message#listFlightsRequest?
[DaveO]
yes norm.
[Ian]
TB: I think what IJ wrote would be just as uncomfortable.
[DaveO]
http://airline.wsdl/ticketagent/message/listFlightsRequest
[Ian]
DC: Names take on meaning by use. They DO take on meaning as a result of GET. You walk into a room and say "Dan". If I turn my head, that encourages you to associate the name "Dan" with me.
RF: If I say to you "that's a red button" and you agree, then we've named that thing a red button.
[Norm]
Context sensitive names are useful, but we're talking about context-insensitive names; names that are globally unique.
[Ian]
DC: Yes.
RF: So if we say that the namespace doc specifies a hierarchical namespace underneath the root identifier, then surely we've named them.
TB: RF's proposal seems appealing on the surface. Seems to be consensus that people want to do this.
PC: How do you know what the namespace is?
TB: That's given.
DC: You can't undo it, in general.
TB: Yes.
TB: The problem with that - suppose I have 3 different xml schemas for a namespace. You'd have different hiearchical fan-outs depending on which schema you're talking about.
[DanC]
(being able to undo the combination of namespace name with localname (etc) is one of the desierata for issue 8)
[Ian]
TB: Solution to problem - address one of your resources in your RDDL documen.t
NW: I.e., add an indirection.
DO summarizing:
  1. There'd be a URI that gives you a RDDL document, then
  2. # some section, then...
[DaveO]
http://rddldocumenturl#wsdlsection/travelagent/message and so on?
[Ian]
DO: I hear that use of # is not appropriate since it's not a fragment, it's an abstract thing. Also, I hear people saying "/" is fine for distinguishing namespace portion and conceptual element.
TB: I'd like to squeeze the "#" out of the middle.
[Zakim]
DanC, you wanted to reply to know what to do with it just from the name
[Ian]
DC to PC: In general, you don't know what a name means just be looking at it; you need more information about it.
DC: I know that " knowing what to do with it just by looking at it" is *not* a requirement; it conflicts with the principle of URI opacity. I need to think about this before agreeing to this.
DO: There is another solution - don't define things abstractly. If you are going to define things in WSDL, use the frag id syntax - if you want to talk about something name pieces of your wsdl documents.
[DanC]
I need to think about #-less proposal before agreeing to them.
[Ian]
DC: You shouldn't define things by their syntax. A message is a message. WSDL should be able to specify messages and it should be possible to have other syntaxes.
TB: I thought I heard some agreement around the following:
  1. People think that what the WSDL WG is trying to do is reasonable in starting with a namespace name as a basis for identification
  2. Reasonable to want to have a hierarchical naming scheme in their conceptual framework.
  3. Seems reasonable to want to tie this together in a URI
TB: At least some of us have grave concerns about use of "#" in the originally presented example (flies in the face of RFC 2396). Therefore, the TAG and interested parties need to find a way to achieve these worthy objectives.
DC: It seems to me to be more cost effective to say "don't use the same name to name 2 different things."
[DC suggests that he needs to reflect offline]
TB: Will work in this area also help us with schemas?
DC: Yes, this is issue 6/14/8!
[DaveO]
I can volunteer
[Ian]
Action TB: Summarize TB's opinion on this discussion and relation to other issues.
Resolved: DO is owner of new issue
DO: I'd like range of possible solutions indicated.
PC suggests that DO does so by responding to TB's post.
DC: I still intend to respond on issue 6.

2.2 Architecture document

See also: findings.

  1. 21 Mar 2003 Editor's Draft of Arch Doc:
    1. Completed action IJ 2003/03/17: Draft a new hybrid that incorporates intro of 6 Feb draft into 21 Feb version.
    2. Action DC 2003/02/06: Attempt a redrafting of 1st para under 2.2.4 of 6 Feb 2003 draft
    3. Action DC 2003/01/27: write two pages on correct and incorrect application of REST to an actual web page design

      DC: Some progress.

    4. 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.
    5. Action CL 2003/0127: Draft language for arch doc that takes language from internet media type registration, propose for arch doc, include sentiment of TB's second sentence from CP10.
    6. Withdrawn action TB 2003/01/27: Develop CP11 more: Avoid designing new protocols if you can accomplish what you want with HTTP. DC suggested describing GET/PUT/POST in a para each, then say "if your app looks like that, use HTTP". Proposal from TB to withdraw the proposal.
    7. Action DC 2003/03/17: : Write some text for interactions chapter of arch doc related to message passing, a dual of shared state.
    8. See PC's email on feedback from Tech Plenary; see also minutes of TAG session at Tech Plenary

      The TAG thanks Susan Lesch for good minutes!

[DanC]

(I apologized for not doing my bit on issue 6 yet, didn't I? If not, I hereby do so.)
[DaveO]
BTW, I was totally wrong about the location for where I did the whiteboard on wsdl's use of namespace names. It was boston, not hawaii. How I confused the 2 locations, I have no idea.
http://www.w3.org/2002/11/18-tag-summary#RDDL
[DanC]
at a glance, new intro looks good
[Ian]
IJ Two questions:
  1. Leave scenario up front?
  2. end this doc to TR page?
DC: At a glance, I like the new intro
TB: I think this is good. I have some nits, though. I'm a little embarassed about lack of progress on rest of document, though.
RF, PC: Publish
[DanC]
I could live without the "1. Starting with a URI" bit. It's abstract. I could live with going straight to the concrete scenario. but I can live with 5 lines of (what I consider) inessential stuff.
[Ian]
TB, RF, SW: I think that "About this doc" is a bit far from the top.
[DanC]
I could live with putting "about this document" in the SOTD.
[Ian]
TB: How about losing the summary of points?
[Agreement that the list is handy for navigation purposes]
TB: Propose to move summary of principles in TOC. Work right into the flow of relevant sections.
[Roy]
next time plus one
[Ian]
IJ will record TAG's suggestions for draft after this TR page draft.
[DanC]
I don't mind a resolution to publish; I just noted we don't need one, having decided last week.
[Ian]
DC: On behalf of URI CG, when are we going to last call? If it's different from June, please notify me.
TAG agrees to request publication of 21 Mar draft.

2.3 URIEquivalence-15

Issue URIEquivalence-15.

[Ian]
DC: I'm particularly interested in IRIEverywhere and URIEquivalence.
RF: We had URI meeting at IETF meeting. I presented on issues related to URI spec. Feedback about creating a URI BNF element was that it would be confusing.
[DanC]
# summary of URI BOF meeting Larry Masinter (Fri, Mar 21 2003)
[Ian]
RF: Not much feedback or suggestions for better terminology.: On MD's IRI - pretty much consensus in the room that IRIs not contain delimiters of URIs.
[IJ wonders whether this means that special meaning will be same in both IRIs and URIs]
RF: For URI spec, we expect go to last call sometime end of June. Progress of IRI spec depends on URI spec.
TB: Aren't we done with URIEquivalence? RF has already taken up text (draft 4 from Tim Bray).
[DanC]
(reviewing records of http://www.w3.org/2001/tag/ilist#URIEquivalence-15)
[Ian]
SW: Are we expecting a finding of URI Equivalence?
TB: When it showed up in 2396bis, I thought that was sufficient.
RF: Yes, I think that's best.
TB Proposal: Close URIEquivalence-15; TAG has proposed text that has been incorporated in an IETF draft. People should write to authors of that draft.
DC: Do we have sufficient trust in handing it off? Are we endorsing existing IETF draft or ultimate RFC?
RF: Is an endorsement necessary?
DC: Our records should include an answer to that question.
Action SW, PC: Review IETF draft to see whether text satisfies URIEquivalence-15.

2.4 contentTypeOverride-24

[Ian]
DC: The server gets to say what the media type is. The document can't override what the server says.: SMIL 2 spec also has this. That Rec has a similar bug in it. Apologies. I suggested that, like HTML docs, to use hints. They responded that server managers or servers don't get this right. They've come back since then with an intermediate position (i.e., when server is clearly misconfigured). I still can't agree to it.
IJ: Tie-in to Xinclude coercion of media type.
DC: "What the server says is right, even if the server is misconfigured. Don't mask bugs.": But the problem with my position is that it's pushing water uphill.
TB: This is not just theology. This kind of sniffing almost always leads to bad results.
IJ: I thought CL had an action on this w.r.t. errorHandling-20.
[DanC]
http://www.w3.org/2001/tag/2002/0129-mime.html#consistency
[Ian]
TB: I got hosed by browsers, when CSS isn't served as text/css. Some browsers silently mask bad server behavior. Hard to find the source of a problem.
RF: Problem is browsers that don't obey specs.
[TBray]
Problem is that this draft spec is going to *mandate* not obeying the spec
[Ian]
Agreement with DC's email to Voice Browser WG: TB, NW, SW, DC, PC, DO
DC: My message didn't say much about why. We need to provide rationale. TB just told us why it's not right.
Action IJ: Draft up some language; make connection to error-handling issue. TAG position with rationale why to not override server value of content type.

2.5 namespaceDocument-8

[Ian]
TB: We may need TBL for this one.
[DanC]
See discussion at 17 Feb meeting
[Ian]
DC: One objection I had - doesn't talk about modularization.
TB: This hasn't been fixed.
DC: It's not acceptable as is because it suggests that you build invalid HTML documents.
[DO drops off]
DC: I think this is something of a minor point; but in general I'm less interested in HTML solutions than RDF solutions
TB: How do you solve the HTML problem?
DC: Different DOCTYPE (see HTML Modularization spec)
TB: Jonathan did that for a previous version...
[Discussion of what to do with this document.]
TB: I propose that, if we agree to the content of the proposal (modulo objection from DC), that this be put on the Rec track.
[DanC]
(my comment about DTD validity seems to be unminuted)
[Ian]
DC: For me to agree to proposal, it has to say that this spec is not the only option and that RDF and XML Schemas are examples of other options
TB and DC disagree on whether XML Schema - as -namespace doc is bad idea or reasonable idea.
SW: I am reticent about whether TAG chartered to put this kind of doc on Rec track.
DC: Would an AC rep be annoyed at TAG doing this, where there was no normal CFP?
[SW, PC agree that this is sensitive]

2.6 Issues that have associated action items

3. Other actions

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/04/03 21:51:53 $