W3C | TAG | Previous: 28 Oct teleconf | Next: 11 Nov

Minutes of 4 Nov 2002 TAG teleconference

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

1. Administrative

  1. Roll call: TBL, SW (Chair), TB, DC, NW, PC, RF, IJ (scribe). Regrets: DO, CL
  2. Accepted 28 Oct minutes
  3. Accepted this agenda
  4. Next meeting: 11 Nov. Regrets: RF (and possibly for 18 Nov).

1.1 Meeting planning

TAG presentation at AC meeting

TAG face-to-face meeting

SW: I imagine four slots. One on namespace docs, one on AC meeting prep. Other two? See proposal from Tim Bray (TAG-only)..

[Ian]

DC: Let's talk about document formats.
SW: Please email me input to the ftf agenda by the end of this week.
DC: Arch doc doesn't say much about a self-describing Web (following your nose from one doc to another to build context).
DC: TBL, do you believe this is web arch doc? Can we discuss this at the ftf meeting? TBL can you write something in advance of the ftf meeting?
SW: See RF's posting from today, which I think touches on this topic somewhat.
DC: I hadn't read it from that angle.
DC to TBL: Have you written on learning what document X means by following links from X->Y, where you know what Y is?
TBL: I think that's captured by "grounded documents" in "Meaning".

Action DC: Review Meaning to see if there's any part of self-describing Web for the arch doc.

Completed Action TB 2002/10/28: invite Jonathan Borden to the meeting (afternoon) to discuss RDDL.

TB: Bad news is that Jonathan won't attend meeting; Good news is that JB and I have reached agreement and I will be posting something about RDDL in the next few days.

2. Technical

2.1 Potential issue re consistency XQuery/Xschema

See issues from TB and responses from PC (TAG-only).

[Ian]

TB summarizes his issues: I have some technical issues with directions proposed by Query WG. Sharpest aspect is that parts of Query require XML Schema semantics. I sent info to XML Query WG; received a short reply; since then I've received longer replies from individuals of the group.
My latest message is an attempt to break down the problem. This may be a process issue rather than an arch issue. We are moving beyond DTDs (after decades) into new territories of schemas. It seems to me at this point highly architecturally unsound for any really important Recommendation to bet the farm on a particular schema language. XQuery is bigger than it needs to be. The WG has done the sensible thing of defining Basic Query (leaving out most of schema bits). There needs to be architectural pressure on groups to do less; ship sooner; ship simpler.
PC: Sorry for not replying in a more timely fashion to TB's points. On the topic of required integration: WG chartered (twice) to use XML Schema. There haven't been comments prior saying that this is a bad thing. If this dependency is to be changed, then Query WG needs to be rechartered.
[timmit]
Firstly, I am surprised that TimBray is not encouraging interdependence between w3c specs - see HTML and Xlink discussion - PC
[Ian]
PC: This makes this a process issue. IMO, the primary concern in public fora is not dependency on xschema. But rather whether update language is critical (public split 50/50). On living in a multiple-schema world: Just because someone waves a standards banner does not mean that the XML Query WG has to change its plans and delay its work to pay attention to such a banner waver.: Perhaps the XML world needs an abstraction that would include the various schema languages. I think there's a work item in the schema charter that covers this item.
From XML Schema WG charter: "interoperability with other schema languages such as RELAX-NG and Schematron"
On item three on simplicity: We have worked hard to meet our requirements. To come along and say that the requirements are too big surprises me. I don't think that WGs at W3C should be constrained to pursuing only small specs.. Basic Query handles Schema Part 2. If we publish Basic Query as our only deliverable, we would not meet our requirements. I don't think that at this point in time we should split our deliverables given the progress we've made on the document. I think it's ok that the query spec is big. Some of the size has to do with clearer expectations about interoperability. TB has identified a long-term goal -- clearer relationships among schema specs -- but I don't think that this should affect Query 1.0. There are a number of XQuery 1.0 implementations, even prior to last call (both Member and non-Member implementers). So TB's arguments sway me less since we have so much implementation experience that suggests we are doing the right thing.
DC: Is PC arguing that this or is not a TAG issue?
PC: Could be that the TAG issue is on multiple schema languages. Perhaps we could synthesize an abstract model for PSVI processors.
DC: Is there an issue in the first place?: I'm convinced there's an issue given the substantive email exchanged.
TB: Tie-in to XLink is a big bogus; the arguments in that case were purely technical, not about it being a W3C spec.: In the community of Web designers, there is a wave of horror at the astounding complexity of schema and xpath 2.0. A strong feeling that something has gone amiss somewhere.
DC: I have heard similar.
TB: I am not simply running off at the mouth here, but I think accurately representing a feeling that's out there.
[Zakim]
DanCon, you wanted to share concerns from the public about XML schema "leaking" into other specs; mostly XPath and to say that nearing last call is *exactly* the time to revisit and confirm or reconsider requirements.
[Zakim]
Timmit, you wanted to say that this is primarily an architectural issue in the sense of high-level modular design. It is a question of whether a flexible interface to the schema language should be provided. Of course the process and social issues are intertwined.
[Ian]
TBL: The question is architectural (whatever the charter said).: Modularity is a good thing; can the specs be more modular? PC and TB do talk to different people (and it's good to hear from all of those people). It would be obviously costly to do anything to XQuery. I read Xquery and it seemed pretty straightforward to me. PC's social point holds (cost of change).
TB: Query allows querying by types. Allowing query by those 19 data types seems reasonable.
[TBL summarizes that TB's concern is about the dependency on part 1 of XML Schema.]
SW: Is the focus on a dependency on a single schema language or more specifically on XML Schema?
[Stuart]
s/Schema/Query

[Scribe is unsure whether this substitution is appropriate.]

[Ian]
TB: I think that PC is correct -- there's a key technical question about whether XML Schema is a cornerstone of future XML specs.
[DanCon]
well, tim, techincally, XML Schema part 2 depends on XML Schema part 1.
[Ian]
PC: I think the issue is more about multiple schema languages.
[Zakim]
Timmit, you wanted to say that this sort of choice has to be made in each case on its merits.
[Ian]
TBL: I am concerned by extreme stances such as "one should one always use w3c specs"; each case is different. Several good principles here - reuse stuff; modularity. Need to consider each case. Just talking about the schema, case I think that it's not interesting to reset the Query WG. What is possible is for someone to find a clever way of achieving what is required. I haven't understood whether "Basic" is what TB needs. Is Basic what TB prefers, or is Basic not adequate (and needs tweaking)?
SW: Please frame comments in terms so we can define this issue.
TB: I think that it's a good thing to have lots of schema languages out there since this area is new. We don't have enough experience to know which schema language meets which needs. I highly approve of XQuery Basic and would strongly recommend that the WG release that on a separate Rec track. It might even shorten time to Recommendation (for that part of the spec). I have argued (with specifics) about how query/schema can be decoupled. I haven't heard substantive replies to my specific syntax.

TB: issue proposal: "Schema languages: What can be said about multiple existing schema languages and their appropriate uses in W3C and the Web more generally?"

TBL: More specific than "What can be said about...?"
TB revised proposal: "Given the existence of more than one XML schema languages; what architectural implications does the use of a particular language have? To what extent is it useful to bind to all schema languages or a particular one?"
DC issue proposal: "To what extent should schema be integrated into xpath and xquery?" At confs I hear concerns about XPath.
NW: I have a lot of the same concerns as TB. Though I'm not sure what the issue is, exactly. I think the pragmatic issue will be setting the conformance levels right. Substitution groups and inheritence look like they'd be hairy to decouple.
[DanCon]
sigh. conformance levels are evil. This was a priniciple of XML 1.0 (which XML 1.0 didn't quite meet, actually) and it continues to be important.
[Ian]
PC: What about extending DC's proposal to xforms and wsdl?
DC: Not concerned about those as much as xpath, and xquery.
NW: I'd support DC's proposal
PC: I vote against the issue as proposed. XQuery 1.0 handles DTD and XML Schema. It's not been on the WG's work plan to handle other schema languages. And it seems that the XQuery WG charter has as a work item addressing additional schema languages. I don't understand why the TAG has to take this up since the WGs have items on their work plans.
NW: I don't think that there's evidence that xquery and xpath will support xml schema and dtds equally well.
RF: There seems to be an awful lot of support for Relax
SW Proposed: Adopt as a new issue "To what extent should xml schema be integrated into xpath and xquery?"
PC: I oppose this as an issue; I don't see what the architectural issue is from this wording.
For: DC, TB, NW.
Abstain: TBL, RF, SW
PC: If there an arch issue, I think it's about how schema languages interrelate. I'd like to take offline with TB and refine this.
No issue accepted at this time. No action item assigned.

2.2 Use of fragments in SVG v. in XML

[Ian]
DC proposed issue: "Use of fragment identifiers in XML". I think that CL might disagree with me, but I take that as evidence that there is an issue.
TB: Is there not already an architectural slam dunk: RFC2396 says that what comes after # is up to the spec.
DC: There are cases where two specs define what happens. It seems to me that it means something, but it doesn't have to be exhaustive or exclusive.
TB: I could almost see a principle that says "When there is a language that might be served wtih one of multiple media types, inconsistencies in meaning for frag ids is harmful."
SW: RFC2396 also discourages inconsistency.
TBL: We can ack the inconsistency in the architecture (e.g., when coneg is used). You can serve an HTML page as text/plan. You could serve up, similarly, a bag of bits using the appropriate mime type to give the meaning of a dog or car.
TBL: I have resisted bringing in mime types. I've become more comfortable with the idea of using mime types to give a particular view on data.: I think there is an issue here that we should write up. Fortunately, I think we can write it up and resolve it.
[Straw poll]
PC: I'm uncomfortable about doing this without Chris Lilley present.
DC: That doesn't convince me that we shouldn't call the question, see if there's support today, and moving on.
SW: Active support for the proposed issue?
For: NW, TBL, DC, SW, RF
Abstain: PC, TB
[Norm]
People would like to be able to inject processing instructions (not PIs, but semantics) into fragment identifiers. That's where I'm feeling the pain today.
[Ian]
Resolved: Accept new issue fragmentInXML-28.
Action IJ: Add fragmentInXML-28 to issues list.

2.3 Findings

See also: findings.

  1. Findings in progress:
    1. deepLinking-25
      1. TB 2002/09/09: Revise "Deep Linking" in light of 9 Sep minutes. Status of finding?
  2. Findings versioning
    1. SW 2002/09/09: Discuss with IJ versioning of findings. Done.

On findings versioning:

DC: Formalizing this is burdensome; I feel differently for Tech Reports.
SW: I didn't want people to refer to things that would change.
DC: Such is life. Do other people really want to do this?
SW: For me, this is what I'd like for findings.
PC: Works for me.
NW: It works for me, too.
IJ: Number of findings per year (6 in 2002) seems manageable.
Resolved: Accept this proposal for the time being.
Action IJ: Send this policy to www-tag and make available from/on findings page.

2.4 Architecture document

See 29 Oct 2002 Architecture document

  1. Completed action RF 2002/09/25: Propose a rewrite of a principle (rationale -> principle -> constraint) to see whether the TAG prefers this approach. It was suggested that the example be about HTTP/REST, as part of section 4.
  2. Completed action TBL 2002/09/25: Propose text on information hiding. (From 24-25 Sep TAG ftf: "The principle of information-hiding is contrary to global identifiers....Shall we put in the document something about information hiding/independent design of orthogonal specs? You should should not be able to write an xpath to peek into http headers....") [Done]
  3. Action CL 2002/09/25: Redraft section 3, incorporating CL's existing text and TB's structural proposal (see minutes of 25 Sep ftf meeting on formats).
  4. Action NW 2002/09/25: Write some text for a section on namespaces (docs at namespace URIs, use of RDDL-like thing).
  5. Completed action DC 2002/10/31: Resend redraft of arch doc section 2.2.1 on URIEquivalence-15. DC and IJ discussed on 30 October. Should IJ incorporate those comments in next draft?
  6. Action IJ: Incorporate DC and IJ comments about URIEquivalence-15 into next arch doc draft.
  7. Completed Action IJ 2002/10/28: Include link to IRI issue from this point; leave as good practice note. Done in 29 Oct 2002 Architecture document.

[DanCon]

Roy writes "I give up" as if to say "please withdraw this action" but I found his message quite responsive to the action.
[Ian]
RF: Regarding earlier question: are xquery and xml schema orthogonal?
TB, DC: I found the approach appealing.
IJ, SW: Same here.
IJ: "Change is inevitable, and therefore evolution should be planned." Seems like "evolution shoudl be planned" is for agents, not the system. Does "requirements" mean requirement on the designers or the system?
RF: "The system needs to be be able to evolve since change is inevitable."
TB: "Evolution should be planned *for*; when change happens things should not fall apart."
TBL action regarding info hiding done.
CL Action about chapter three not done.
IJ: What are our expectations for doc before AC meeting?
PC: I am more comfortable approving 29 Oct draft and approving a bigger change at the ftf meeting.
DC: I'd like IJ to get as much done as possible by 13 Nov, with approval with one other TAG participant's review.
Resolved: We might not get a doc out by 13 Nov, but ok for IJ two other participants (for this draft) sufficient to get to TR page.
IJ: I will try to get a draft with some of RF's proposals by Thursday.

TB, SW: We commit to read and give feedback.

[DanCon]
if it's out by Thu, I intend to read it by Monday

2.5 Postponed

  1. IRIEverywhere-27
    1. See comments from Paul Grosso (asking the TAG to do this quickly).

      SW: This will be a priority agenda item for the 11 November meeting.

      Action IJ: Invite Martin Duerst to the 11 Nov meeting.

  2. Status of URIEquivalence-15. Relation to Character Model of the Web (chapter 4)? See text from TimBL on URI canonicalization and email from Martin in particular. See more comments from Martin.
    1. CL 2002/08/30: Ask Martin Duerst for suggestions for good practice regarding URI canonicalization issues, such as ~ v. &7e and suggested use of lower case. At 16 Sep meeting, CL reports pending; action to send URI to message to TAG.
  3. xlinkScope-23
    1. Coordination with XML CG? See Notes from XML CG call 10 Oct 2002 (Member-only)
  4. namespaceDocument-8
    1. Action TB 2002/09/24: Revise the RDDL document to use RDF rather than XLink. Goal of publication as W3C Note.
  5. contentPresentation-26
    1. Action CL 2002/09/24: Draft text on the principle of separation of content and presentation for the Arch Doc.
  6. rdfmsQnameUriMapping-6
    1. The Schema WG is making progress; they will get back to us when they're done. See XML Schema thread on this topic.
  7. uriMediaType-9:
  8. Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?
Ian Jacobs, for TimBL
Last modified: $Date: 2002/11/04 22:53:25 $