W3C home > Mailing lists > Public > www-tag@w3.org > June 2002

[Minutes] 17 June TAG teleconf (Infoset/PSVI, XLink, Style properties, Qnames, Mime registration)

From: Ian B. Jacobs <ij@w3.org>
Date: Tue, 18 Jun 2002 16:15:33 -0400
Message-ID: <3D0F94E5.80508@w3.org>
To: www-tag@w3.org


An HTML version of the minutes [1] is available,
quoted as text below.

  - Ian

[1] http://www.w3.org/2002/06/17-tag-summary

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

1. Administrative

     1. Roll call: All present  - Tim Berners-Lee, Tim Bray, Dan
        Connolly, Paul Cotton, Roy Fielding, Chris Lilley, David
        Orchard, Norm Walsh, Stuart Williams, Ian Jacobs (Scribe)
     2. Next meeting: 24 June. Regrets: DC and TBL.
     3. Accepted 10 June minutes
     4. Confirmed status of completed actions

   1.2 Completed actions?

      * IJ: Add to issue namespaceDocument-8 as
        background links to discussion by James Clark
        (see email from TB).
      * IJ: Update and publish "URIs, Addressability, and
        the use of HTTP GET". Done.
      * NW: 2002/6/03: Tell I18N WG that TAG has agreed
        to comments from CL with amendments from NW.
      * NW 2002/05/20: Draft a finding for
        formattingProperties-19 (Done)
      * RF 2002/06/10: Send thank you note to XMLP WG.

2. Technical

     1. New issues:
          1. Augmented infosets, PSVI
          2. Scope of Xlink
     2. Findings in progress
          1. TAG Finding: Consistency of Formatting
             Property Names, Values, and Semantics
          2. QNames as Identifiers
          3. Internet Media Type registration,
             consistency of use
     3. Postponed

2.1 New issues?

2.1.1 Augmented infosets, PSVI

Source: email from TB. Accepted as

Action IJ: Add to issues list.


       TB: What was bothering me was that augmented
       info sets could only come about through schema
       validation (namely just one).

       I 2nd the proposal to accept this issue. I'm
       not sure exactly what it is or what we'll do
       about it, but it's clear that doing something
       is worthwhile.

       TB: That strikes me as wrong. It may be worth
       specifying type-augmented infoset in
       abstract/generic terms. See email from Noah.

       "(b) Applications that depend on a PSVI now
       require a very complex,
       heavy-weight schema validation process, rather
       than a relatively simple
       parsing process." -- clark,
       02Jun/0119.html. Hear hear.

       CL: Seems like same as using DTD to get
       information and using it to enforce validity?
       TB: Seems that PSVI repeats some mistakes DTDs
       made (conflation of two orthogonal issues).
       PC: Why is this a TAG issue and not to be
       dealt with in Schema/Query WG?

       A reservation: it's not clear how this is "web
       architecture" as opposed to 2nd-guessing a
       WG's decisions. But though it's not clearly a
       web-architecture issue, it is a W3C
       architecture issue, in that it affects many

       TB: It seems to me that it cuts across work.
       Maybe all the TAG needs to do is to raise this
       as an issue and ask the appropriate group to
       work on it. The important arch principle here
       is "where do types come from?" Types only
       being meaningful in context of PSVI is
       problematic, I think.
       DC: I share PC's concern about TAG
       second-guessing other WG's work. It's clearly
       W3C architecture if not Web architecture. If
       we let each WG optimize locally, we may not
       get a global optimization. I support accepting
       this as an issue.

       [aside] Is there an XML processing
       architecture WG?

       NW: I share some of PC's concern as well. I'm
       not certain that some WGs will look at this at
       a broad enough level. I second supporting
       accepting this issue.
       SW: Can we take this to XML Core?
       PC: No. There is broad representation in this
       area. There are several groups already working
       together on this. (E.g., schema, query,
       xforms, ...)
       TB: I read the query data model piece. It
       talks about the PSVI and clearly creates the
       impression in the reader's mind that the only
       way to get type info is through a w3c schema
       parser. I think that's wrong.
       PC: I'm reluctant to have the TAG take up an
       issue that questions some of the rationale why
       the Schema WG was created. E.g., schema
       charter accepted to model DTD functionality.
       TB: It is my opinion that annotating infosets
       through types is a good idea. But there are
       other ways through schema validation. And that
       annotating with default values is almost
       always a mistake. [Scribe would like review of
       this statemetn.]

       Indeed, the schema WG charter was accepted 4
       years ago. i.e. we have 4 years of experience
       since then.

       DO: Maybe what PC is hearing is that this is
       an opportunity for the TAG to live up to one
       perceived function - technical coordination
       and expertise. I hear TB saying infoset
       augmentation is more general than schema
       PC: The XML Activity made an explicit decision
       that any WG could augment the infoset since
       the Core WG didn't want to do this as a
       critical work item. A decision was made to
       delegate to the Schema WG to do this. Some
       pieces of thread have not been addressed yet.
       I think TB has not addressed Schema WG as an
       individual. If you are going to define
       user-defined operators, the type system can't
       be completely pluggable. Otherwise query will
       have to be so flexible that we won't get it

       hmm... paul's point that we should persue the
       matter with the WG 1st... I could live with

       yes, that is the principle we use as the first

       RF: I think the Schema WG has approached the
       issue from the perspective of schemas. TB
       wants to approach from the perspective of the
       Infoset. Why is it necessary to get Schema
       WG's permission here?
       TB: I think that there are a bunch of issues
       here well worth discussing: type-augmented
       infosets (outside of query), and would be
       excellent to do this in an interoperable
       manner. Granted, there should be a liaison
       with the Schema WG.

       I think TB has identified a gap in the
       architecture. So the real question is who
       should be asked to address/fill the gap?

       TB: We don't know what they think yet. I
       remain convinced that this is an issue for the
       CL: How does this process differ from a
       charter proposal? I agree with TB's point
       about augmention-broader-than-schema. When
       HTML people wanted to use XLink, they wanted
       to through augmention rather than through

       CL said my point

       CL: But I also understand PC's point that
       people should talk to existing WGs where this
       is in scope. What would more discussion in the
       TAG add?

       I learned quite a bit about XML schema
       requirements around PSVI stuff in an
       xmlschema-dev thread.

       TB: We could ascertain whether there are apt
       to be infoset augmentation use cases outside
       of schema. And is it an arch principle that
       there should be a std way to do infoset
       augmentation and to exchange such
       augmentations (i.e., syntax). And another
       principle - is it sufficient for Query WG to
       rely on current version of augmentations as
       proposed by Schema WG.
       PC: One of the comments made at the processing
       model Workshop: fallacy in the augmentation
       design was that everyone who wishes to augment
       assumes they are last. Question about whether
       XML Activity will take up this challenge was
       recently put to the AC.

       I don't think this issue is exactly what was
       discussed at the xml processing model workshop

       TBL: Just because a WG is going to work in an
       area doesn't mean that TAG discussion is
       inappropriate in that area.: I think it's
       still useful for the TAG to sync up with WGs
       (especially early, when a WG may have
       different ideas about architecture).

       DO: If PC's thesis is correct (some work done
       in W3C about processing) then we could say
       "watch this group to see what they do."

       Query datamodel says:

       The data model is defined in terms of the [XML
       Information Set] after XML Schema validity
       assessment. XML Schema validity assessment is
       the process of assessing an XML element
       information item with respect to an XML Schema
       and augmenting it and some or all of its
       descendants with properties that provide
       information about validity and type
       assignment. The result of schema validity
       assessment is an augmented Infoset, known as
       the Post Schema-Validation Infos

       I have grave arch concerns with this assertion

       DO: I don't think we want to have issues about
       tracking work of other groups to see if they
       are doing the right thing.
       SW: What about having a round of discussions
       with Henry Thompson and others?
       PC: That's my point - discussion has not been
       sufficient yet.
       DC: I'm happy to ask the XML Schema WG to do a
       version that has PSVI separate from
       validation. Maybe they would do this. They are
       collecting requirements. I'd still rather it
       be an issue for us anyway.

       Sounds as though if there is this much
       discussion about it, then it may be an issue.

       Action DC: Talk to XML Schema WG about PSVI.
       Report to tag, who expects to decide whether
       to add as an issue next week.

2.1.2 Scope of Xlink?

Source: email from TBL. Accepted as xlinkScope-23.

Action IJ: Add to issues list.


       I have some info background on xlink

       TBL: I thought that "hlink" was for GUI
       semantics. Should RDF be used or schema

       xlink:href --> xmlns supported. Is that okay?

       Yes, it implies namespace support. xlink is
       *not* only for hyperlinks

       Should xlink be required for
       (a) all URI parameters
       (b) all URI params pointing to documents which
       are hyperlinked fr om this one
       (c) nothing it is optional
       (d) none fo the above
       (e) all the above

       CL: xlink is not just for hyperlinks. It's
       chartered to support replaced content (like
       TBL: I would include image embedding as part
       of (my concept of) hypertext.

       CL: Some W3C WGs coming up with other
       mechanisms that rely on PSVI and hence Schema.
       The notion of having a cell phone using a
       schema strikes me as "not entirely thought
       DO: Why should we look at this as an issue
       given what the charter of xlink says?

       Using a schema "to find out where the links
       are", especially since it needs a link to get
       the schema.

       DO: Shouldn't people talk to the WGs
       responsible for these technologies?

       Interesting... hyperlinking only... SVG went
       and used it for symbol references, which isn't
       hyperlinking, is it?

       RF: W3C has to do a better job of setting reqs
       on its specifications. When it started, xlink
       was meant to be general links on the Web. If
       only for hyperlinks, that's confusing.

       Depending on whose definitions of 'hyperlink'
       you use

       TBL: People's terminology varies (a source of
       confusion) and that becomes a TAG issue.

       Again, it seems there's plenty here to justify
       the time of the TAG to discuss this issue.

       NW: The xlink spec seems to have all the
       necessary machinery to provide roles for fully
       generalized linking. I thought that all links
       would be based on xlink.
       TBL: (Clarification) - what do you mean by a
       link? Does a reference to a piece of a BNF
       expression in a speech grammar be a link?
       NW: Yes - if you point from here to there, use
       an xlink.

       Order? would the chair please ask if anybody
       wants this to *not* be a TAG issue?

       Agree it should be a TAG issue

       TB: I propose we accept this as an issue -
       domain of application of xlink. Are parts
       mandatory? Xlink represents a lot of work and
       agony. Would it help if TAG made
       recommendations? I think that's worth an
       DO, PC: Objections to making this a TAG issue.
       DO: I observe that one of the fundamental
       issues that came up on xlink charter
       discussions was - when you start doing more
       general hyperlinking, you want to give the
       author a better understanding of processing
       model when link occurs. I thought xlink was
       not meant to be used for all linking (e.g.,
       some from database community not satisfied
       with that).

       PC: +1 to DO's comments.
       TB: I'm uncomfortable with history determining
       (mechanically) whether we decide to accept
       arch issues.

       The XLINK spec IMHO is made for GUI links.

       TBL: The architecure is "You shall use URIs."
       not "You shall use xlink". If you try to use
       Xlinks for semantics, I'd find that RDF is
       more generic - I wouldn't force people to use
       RDF for human-readable documents.

       xlink covers all explicit links. There are
       also implicit links and externally-defined
       links that are not covered.

       I've had lots of discussions where, 2/3rds of
       the way thru, folks discovered they had
       different ideas about what "link" or
       "hyperlink" or "reference" meant. I think the
       TAG could save W3C WG's a lot of time by
       spending some time discussing this stuff.
       hmm... interesting policy question... do we
       need consensus to accept an issue? or just

       Having it added as an Issue does have some
       politicaly overtones, yes

       IJ: For me, issues list is just a tool. What
       do people think are other implications of
       putting on the issues list?
       TBL: Right, useful to assign issue number to
       get work done. Even if we make a quick
       resolution. Nomenclature consensus is already

       BTW I think I agree with DaveO on the
       appropriate use of xlink

       Of course, we could always issue a finding
       that "there is no problem". Issue does not
       equate to "clearly broken"

       TBL: Just pointing out what people meant by
       "hypertext links" is time well-spent.

       From TAG charter: "# By a majority vote, the
       TAG must agree to consider an issue as having
       sufficient breadth and technical impact to
       warrant its consideration." We're done with
       this one. This is an issue.

       I don't agree that issue ==> finding

       Nor do i

       DO: I would drop my concern if we get clear
       view of what "issue mean".

       DC: Our charter says "Majority vote" to accept

       Indeed, we don't owe a finding on every issue.
       we owe a decision that we're done with an
       issue. our decision could be "well, we don't
       care anymore."


       IJ: Dispositions may vary.

2.2 Findings in progress, architecture document

See also: findings.

2.2.1 "TAG Finding: Consistency of Formatting Property
Names, Values, and Semantics"

Resolved: Publish "TAG Finding: Consistency of
Formatting Property Names, Values, and Semantics"

Action NW 2002/05/20: Find out source of issue from
CSS WG. Done.

CL: Once Steve Zilles stopped prodding people, people
stopped thinking about harmonization. SVG WG going
down that path, too.

Action NW: Call for initial review on www-tag of this

2.2.2 QNames as Identifiers

Resolved: Announce on www-tag one week review of
QNames as Identifiers (qnameAsId-18).

ACTION NW 2002/06/10: Revise finding by adding
examples. Done.

Action NW: Call for one-week review on www-tag of
this finding. TAG expects to confirm completion next

TBL: I have the feeling that the finding on qnames is
different from other findings. "There's this problem
and it won't go away." [Without saying "It will go
away if you do this.]


       TBL: It's useful to note that (a) this is a
       hole in the architecture and (b) we are not
       patching it over.
       DC: I think that the document already says
       TBL: The hole is that you can't tell when
       something is a qname.

       What TimBL is saying is "you could imagine a
       syntactic signal that would tell you when
       something was a qname"

       DC: Changing XML would not fix the hole. The
       primary use is in XPath. The only thing that
       would fix it is to never do microparsing in
       attribute values or other content.

       Nothing short of a new markup character can
       fix this

       TB: Should status section say this?

       "the table of contents"?

       TBL: What about TOC for "holes".

       IJ: I have started to do this in the arch
       document: create sections entitled "Design

2.2.3 Internet Media Type registration, consistency of use

ACTION DC: research the bug in the svg diagram. There
are two votes to remove the diagram (DC and TB).


       DC: I researched the bug. The bug was smaller
       than expected. MD said lacked context, but not
       more serious bug.
       As it sits, the text around link to diagram
       doesn't set the right context. Nobody but TBL
       said they would miss the diagram.

       The diagram could of course be *revised* not
       removed. People have no issue with a correct
       diagram, surely

       TB: So (a) nuke diagram or (b) change text to
       fix context.
       DC: I18N folks would like it anyway.

       I propose: (a) cut the diagram out of our
       finding, (b) I notify the I18N WG that timbl
       has this nifty diagram they might want to use.

[No resolution]

1. Accept suggestion from Graham Klyne?
2. Any action on dissent from Joseph Reagle?

       TB: People are worried that requiring IETF
       stuff will create bureaucratic delays.

       We are not requiring them to wait until its
       published as an RFC, just to submit the
       registration, yes? (See SOAP 1.2 application).

       That's my experience as well with IETF WG

       TBL: Our experience with speech grammars makes
       me more adamant that the full info required to
       register mime type should be appendix to spec.
       That gets more attention. You have to not only
       show us the language, but exactly what you
       understand from the fact that you get the mime
       type. There are all kinds of last-minute
       tweaks in mime type application since no
       review of it.
       CL: I think that there's a circular dependency
       here (use mime types, get implementation
       experience (which requires a mime type...))).
       TB: I think the issue is real - circular
       CL: I am in favor of proposal to include an
       appendix that has the mime registration
       (developed in parallel with the spec).
       PC: If a WG wishes to skip CR, mime type
       registration necessary earlier. Why is direct
       inclusion necessary, however? Why not link
       normatively to another document?
       TBL: Because the registration process is not a
       standards process. A Recommendation should not
       rely on something if it doesn't have a similar
       level of review.

       may I answer?

       PC: How do we engage the existing IETF process
       to define the mime type? Do we send them the
       entire spec?
       DC: Copy materials relevant to registration
       from spec (appendix) into an internet draft.
       PC: But there's risk of getting out of sync.
       What to do in that case?
       TBL: They can't get out of sync. Every time
       you change you change the rec track doc, you
       change the Internet draft. And we don't allow
       internet draft to change unless w3c spec has
       SW: The internet draft doesn't stay one
       forever, it becomes an RFC at some point.
       RF: Depends on whether informational rfc, or
       just a form,... The confusion on the mailing
       list is whether there is some ordering
       involved. There isn't. There is a separate
       process in IETF land, where there is cut and
       paste from w3c spec->IETF land.

       Hmm... actually, roy makes a good point; the
       internet draft needn't become an RFC; it can
       just be pasted into the IANA registry, with a
       pointer to the W3C spec.

       PC: If this decision is in place, the XMLP WG
       will have to pull a mime type registrationinto
       one of its normative specs.

       [several]: yes, paul.

       TBL: Yes, the primary spec referenced by the

       i.e., the media format definition spec should
       contain the media type definition forms.

       XMLProtocol is about to push XMLP to last
       call. The spec referenced by the registration
       document should include the registration
       document as a part.

       Given that we issued a finding that said it
       should be added 'at CR" and now changed irt to
       "a t last call" then clearly there should be a
       grace period for specs already in, or
       immeduiately about to enter, last call

       DC: Since PC wants to go from last call to PR,
       media type should be included directly in last
       call document.
       PC: The registration has been done.
       Action PC: Convey the desire of the TAG that
       registration be included in soap spec before
       going to last call.
       TBL: If there's some reason why the WG doesn't
       want that information in the spec, I'd want to
       know why.
       TB: I think grace period reasonable but prefer

       yes we are standing by our finding

       [On comments from Joseph Reagle.]

       I read it and am standing by finding. Already

       RF: The main process is that there exists a
       spec somewhere that includes the correct
       forms. They can either be part of an Internet
       RFC....depends on type of media type being
       defined....if global, there has to be an
       Internet RFC saying where the format is
       defined. It doesn't matter if IETF docs go out
       of date.

       I think I understand reagle's objection well
       enough to clarify; though I'd rather Roy did
       it. ;-)

       RF: You still have to submit the original
       DC: Some entries in registry point to specs,
       not informational RFCs.
       RF: That's the old process. There's another
       one in place. I already replied to Reagle.
       Action IJ/PC: Update finding to ensure that
       it's clear that the registration must be part
       of the document at last call if the WG expects
       to skip CR.

2.3 Postponed

1. Architecture document
      1. ACTION IJ 2002/03/18: Integrate/combine
	one-page summaries (Revised 7 June)
      2. ACTION TBL 2002/05/05: Negotiate more of IJ
	time for arch doc
2. Status of discussions with WSA WG about SOAP/GET?
       + ACTION DO/TB/CL 2002/05/05: Pending XMLP
	response, polish up DO's .1-level draft and
	find out what's going on with XForms
       + ACTION DC 2002/06/10: Send note to Web
	Services Architecture WG expressing concern
	about normative binding for GET.
3. RFC3023Charset-21
       + ACTION CL 2002/6/03: Write up the issue in
	the next day or so.
4. charmodReview-17: Confirm that this is closed.
5. 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.
6. If we get here: httpRange-14, namespaceDocument-8

Ian Jacobs, for TimBL
Last modified: $Date: 2002/06/18 20:13:22 $
Received on Tuesday, 18 June 2002 16:18:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:32 UTC