W3C | TAG | Previous: 19 Jan teleconf | Next: 2 Feb

Minutes of 26 January 2004 TAG teleconference

Nearby: IRC log | Teleconference details · issues list (handling new issues)· www-tag archive

1. Administrative (15min)

  1. Roll call: SW, DC, TBL, CL, NW, TB, PC, RF, DO, IJ. For I18N Part of meeting: Addison Phillips, Richard Ishida, Martin Dürst.
  2. Resolved to accept minutes of the 19 Jan teleconf
  3. Proposed to accept TAG activity summary. SW to review within 24 hours.
  4. Accepted this agenda
  5. Next meeting: 2 Feb 2004.
  6. Video meeting 9 Feb. Send agenda items to list.
  7. Resolved to cancel 16 Feb teleconf.

1.1 Technical Plenary

  1. Liaisons: In principle agreements and scheduling.
    1. XML Schema WG would like to meet in principle on Monday.
    2. SVG WG: No perceived need to meet ftf.
    3. HTML WG: IJ still has not heard back from Chair.
    4. Voice WG would like to meet in principle. Possible discussion of shared memory v. message passing. Also possible issue about silent recovery from error.
    5. XML Core: No perceived need to meet ftf.
    6. WSDL: abstract components, marking operations safe in wsdl.
    7. I18N: Continue what we do not conclude today.
  2. Continued action SW 2003/11/15: Take to tech plenary committee the TAG's proposal. See hot topics from SW. Proposal from SW
  3. TAG 2 Mar 2004 ftf meeting page
  4. Resolved: Accept AB invitation for joint dinner 4 March

1.2 TAG meeting schedule in 2004

  1. Action PC 2004/01/05: Propose meeting schedule for next 4 (or so) TAG ftf meetings. Due: 23 Jan 2004.

    PC: Not yet done. Please continue.

2. Technical (75min)

See also open actions by owner and open issues.

2.1 qnameAsId-18

[Ian]

DO: I am satisfied with the TAG accepting this finding.
SW: I have read it and I am satisfied.
PC: +1
TBray: +1
DC: Can you read the part where we say qnames in query are ok?
NW: 4.1 QNames in Other Specifications "The [Functions and Operators] specification, for example, uses QNames to identify functions. This is motivated partly by backwards compatibility with XPath 1.0, but also by the fact that function names share some characteristics with element and attribute names. In particular, the names need to be globally unique so that name collisions don?t occur either between independently developed functions or different versions of the specification."
DC: Drop "equally well"
TBray: I even object to "equally well"
SW: I don't mind taking out "equally well"
DC: Seems best to me to point to the Arch Doc that says "You need a mapping"
SW: Recall there are two issues -
  1. Mapping from qname to URI
  2. Mapping from qualified name to URI
DC: Query specs don't do what Web Arch says, the finding shoudl say that they clash with Arch Doc
[Chris]
that was the 'must that i was referring to ... must provide a mapping to URI
[Ian]
NW: "Specifications that use QNames to represent {URI, local-name} pairs MUST describe the algorithm that is used to map between them." You could argue that the Nov 2003 Query drafts are deficient in not providing that mapping. But that's a comment on the query spec.
DC: In the discussion on the query specs, seems like they are using qnames without mappings to URIs. I'd like the finding to point to the Arch Doc and say "This doesn't follow the GPN in the Arch Doc."
[Zakim]
timbl, you wanted to suggest that "we expect future drafts to be in line with this finding"
[Ian]
TBL: If we are assuming that specs will change, we should say that in a footnote in the finding.
[Zakim]
timbl2, you wanted to say that the distinction is not well made between mappings
[Ian]
TBL: Distinguish between specs as they are today from how we'd like them to be. The finding doesn't bring out the different mappings. The finding is organized by context. But doesn't say which mappings need to be defined.
[timbl]
"There is no single, accepted way to convert QNames into {URI, local-name} pairs or vice versa"
[Ian]
TBL: I think we might want to promote one way - use xml base and namespace...
[TBray]
I suggest we push this back another week, I for one now want to give it a careful read
[Ian]
TBL: Perhaps finding should deal with two mappings more clearly.
SW: "A related TAG issue, rdfmsQnameUriMapping-6, concerns the mechanism by which one can (or can not) construct a URI for a particular QName. We do not consider that issue in this finding."
DC: Then this finding shouldn't talk about the query specs.
[DanCon]
the examples in there are quite good.
[Ian]
TBray: I suggest we push back one more week. I"d like to read it carefully.
Action CL, TB, TBL: Read finding due next week.
TBray: I think it's worthwhile since I think this will keep coming back. I withdraw my earlier +1 given discussion here; subtlety of issue.
[Ian]
TBL: Document should state that this document is only about XML (qnames might be used in other languages).
[DanCon]
timbl: s/in Content/in XML Content/
[Stuart]
it also uses xpointer as an example of a language where qnames get used
[DanCon]
thanks, norm, for playing faithful editor. (2nded by Bray)
[Ian]
NW: I have no plans to make changes before next week.
The TAG thanks NW for his ongoing work on this finding!
The TAG has not yet accepted the finding.

2.2 contentTypeOverride-24

TB, RF expect to review the upcoming draft.

2.3 namespaceDocument-8 activity

namespaceDocument-8

  1. RDDL2 Background from Tim Bray.
  2. grokRDDL.xsl mapping to RDF from Dan Connolly.

[Ian]

DC: TB, did you see my email?
TBray: I thought your RDF mapping was fine.
DC: Please sort out amongst yourselves. I prefer attributes.
TBray: As Eric points out, you can put more structure in a DIV than an A. But I'm not convinced by that point.
CL, TBL, SW: We've watched this thread..
DC: Please prepare for discussion in substance at our video mtg. Please be prepared to give your position (or not) on 9 Feb.

2.4 Discussion with Internationalization WG representatives

[Chris]

I don't see a resolution to 120 from the minutes
[TBray]
Where are we on C120?
Dan: the agreement (see #119) to split puts all the issues on the shelf for me
TBray: Disagree, SW too
[DanCon]
this relates to web architecture how, chris?
[TBray]
Revisiting C117
CL: He asked for a link to text, but they did inline text which is wonderful. But for remaining images, wants links to text
[DanCon]
stuart, how is C117 related to TAG proceedings?
[TBray]
CL: shouldn't cause problems because browsers not required to render
MD: where does the link go?
CL: right underneath the image
[DanCon]
http://www.w3.org/International/Group/2002/charmod-lc/SortByGroup#C117
[Stuart]
http://www.w3.org/International/Group/2002/charmod-lc/SortByGroup#C117
[TBray]
MD: sounds reasonable
[Chris]
http://www.w3.org/International/Group/charmod-edit/#sec-Strings
http://www.w3.org/International/Group/charmod-edit/#sec-CharExamples
[TBray]
Because we as a group blessed Chris' comments collectively
Discussion of how best to achieve desired effect
Agree that CL and the I18n guys will work this out
RESOLVED: C117, pending review by CL
Next: C120
TBray: Have you reviewed this since rewritten?
CL: Expecting input from PC
[Chris]
http://www.w3.org/International/Group/charmod-edit/
[TBray]
PC: I still have a to-do to follow up
TBray: Propose to resolve C120, have a look on restructured drafts
MD: XQuery has a similar problem with underspecification
PC: We followed all of your links and couldn't find the algorithm
Addison: We think we're fine for the moment
[DanCon]
straight to last call? I'd expect a non-last-call WD
[TBray]
<discussion> of plans for future charmod drafts
DC: worried about I18n going straight to last call without intervening draft
MD, Addison: next part 1 has few changes from current text after addressing issues
[timbl]
One can call something "Last Call" if the WG doesn't want to be able to change it, whether or not there are "substantive changes"?
[Zakim]
timbl, you wanted to say One can call something "Last Call" if the WG doesn't want to be abl eto change it, whether or not there are "substantive changes"?
[TBray]
<general discussion of meta-issues; what level should we be critiquing at>
MD: we think these edits are orthogonal to the charmod split
[Ian]
TBray: Two options
  1. Express ourselves satisfied and close C120
  2. Or say we haven't done enough and will need to review it further.
TBray: I'm inclined to go with CL; declare satisfaction with issue C120.
DC: I am opposed to that proposal.
[TBray]
TBray: Suggest we retire C120
DC: Objection on the grounds that I need to see the revised text.
[TBray]
DC: because we haven't seen the revised text
[Chris]
http://www.w3.org/International/Group/charmod-edit/#sec-CollationUnits
[TBray]
DC: doesn't believe this is orthogonal to the split
MD: why not?
[Ian]
DC: Cuz it's not.
[TBray]
SW: call question on C120
Objections: Dan, Roy
[Ian]
Richard: We're here talking today because we think we've addressed your comments. The split won't have a grand effect.
[TBray]
RI: the split is really not going change the text, it's just a partitioning of sections
[Chris]
Propose therefore that we leave 120 open so we can get to the other issues this telcon, please
[DanCon]
"when we split the document, we're not going to be making any changes, really" <- I can't make sense of this.
[Ian]
TB to DC: Will you express objection to any and all issue before seeing the new text?
DC: No. This one is related to the split, some others may not be.
[TBray]
Roy: we expressed happiness with large portions some time ago
TBL: w.r.t. 120, we thank i18n group for taking on our feedback, loooks good, we want to review again post-spliit.
so RESOLVED
[Chris]
C122 - I am now satisfied with the changes as it no longer excludes specs talking about bytes or glyphs where it is sensible to do so.
[TBray]
CL Propose we accept C122
DC: Abstain
so RESOLVED
[DanCon]
C123 Is XML non-conforming?
[TBray]
CL: Propose to accept C123
DC: so XML no longer non-conforming?
[Chris]
We do not think that the exclusion of U+0000 in XML 1.1, or of the C0 range in XML 1.0, is arbitrary; it was done for very clear reasons.
[TBray]
TB: yes, I mean no, I mean yes, XML is no longer non-conforming
RESOLVED to accept C123
C125 next
[DanCon]
3.6.3 contradictory C125 [issue name not very helpful]
[Chris]
It could also be misused to completely change the rendering of some text (in the case of Chinese or Japanese easily to an extent that would completely change the meaning of the visually appearing text).
[TBray]
MD: explanation text in i18n response (I didn't understand)
[Zakim]
TBray, you wanted to express bafflement
[TBray]
TBray: don't understand connection to the PUA
[TBray]
Proposed: For C125, we accept first paragraph but consider 2nd paragraph irrelevant
[TBray]
so RESOLVED
[Chris]
Related point, avoid using character mechanisms for things that are not characters ('pi' fonts). Use small inline graphics instead.
[TBray]
MD: we can make a note and address this point
TB: Propose we accept C126
so RESOLVED
[DanCon]
C126 Should XML allow NCRs everywhere?
[TBray]
C127:
CL: I don't think you understood; I want to encourage IRIs in docs, since wire constraints don't affect them
C128:
[Ian]
TBray: Not very happy about this resolution.
[DanCon]
ACTION DanC: look at C127 "Say that the IRI form is used in the document instance and the hexified URI form when it goes over the wire"
[Ian]
TBray: Are the diffs written up in charmod?
MD: I think there's a whole chapter on referencing Unicode/ISO10646
[DanCon]
C128 Referencing the Unicode Standard and ISO/IEC 10646 http://www.w3.org/International/Group/2002/charmod-lc/SortByGroup#C128
[Ian]
MD: I think it speaks quite a bit to the similarities/diffs.
TBray: I'll go review that.
[Chris]
http://www.w3.org/International/Group/charmod-edit/#sec-RefUnicode
[Ian]
TBray: Please refer to chapters 1-3 of Unicode std. If there are tech diffs, please bring that out.
[Chris]
In addition to the jointly defined CCS and encoding forms, the Unicode Standard adds normative and informative lists of character properties, normative character equivalence and normalization specifications, a normative algorithm for bidirectional text and a large amount of useful implementation information. In short, the Unicode Standard adds semantics to the characters that ISO/IEC 10646 merely enumerates. Conformance to the Unicode Standard implies conformance t
[r12a]
http://www.w3.org/International/Group/charmod-edit/#sec-RefUnicode
[Ian]
IJ: I think Unicode has bidi algo, for example.
MD: Unicode std has bidi algo
[Norm]
XML 1.1 uses the fact that some chars are punctuation! You can't use them in name characters, for example.
[DanCon]
"our note"... are we wordsmithing comment responses? I thought CL was quoting the charmod spec.
[apphillips]
XML namespaces use the Unicode char props: cf. http://www.w3.org/TR/REC-xml-names/
[Ian]
TB Proposal: Don't accept this one yet.
[TBray]
Norm: XML 1.1 uses Unicode properties e.g. you can't use a punct character in a NAME
[Chris]
so for the rest - do we take them to email??
[Ian]
Action TB: Review charmod language re: reference to Unicode std.
[TBray]
TB: not prepared to accept. I will go review latest text. Want a strongly-worded pointer to Unicode spec.
ACTION CL: pull out items that are worth our discussion time Due 2 February.
Addison: i18n group wants to re-publish sometime in February.Wants to make sure that they got through the comments
DC: Publish and I'll tell you if I'm happy
Addison: would really liike people to look at their feedback on comments
CL: will do triage in next 7 days

The TAG did not discuss topics below this line at this meeting.

2.5 New issue?

2.6 XML Canonicalization

3. Issues

Issues that are open and that we expect to close by the end of last call:

4. Status report on these findings

See also TAG findings

5. Other action items

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2004/01/29 17:27:51 $