W3C | TAG | Previous: 10 Jun | Next: 24 Jun
Minutes of 17 June 2002 TAG teleconference
Nearby: IRC log · teleconference details · issues list · www-tag archive
1. Administrative
- 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)
- Next meeting: 24 June. Regrets: DC and TBL.
- Accepted 10 June
minutes
- Confirmed status of completed
actions
2. Technical
- New issues:
- Augmented infosets, PSVI
- Scope of Xlink
- Findings in progress
- TAG Finding: Consistency of
Formatting Property Names, Values, and Semantics
- QNames as Identifiers
- Internet Media Type
registration, consistency of use
- Postponed
2.1 New issues?
Source: email
from TB. Accepted as augmentedInfoset-22.
Action IJ: Add to issues list.
[Ian]
- TB: What was bothering me was that augmented info sets could only
come about through schema validation (namely just one).
- [DanCon]
- 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.
- [Ian]
- TB: That strikes me as wrong. It may be worth specifying
type-augmented infoset in abstract/generic terms. See email
from Noah.
- [DanCon]
- "(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, http://lists.w3.org/Archives/Public/www-tag/2002Jun/0119.html.
Hear hear.
- [Ian]
- 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?
- [DanCon]
- 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 WGs.
- [Ian]
- 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.
- [Roy]
- [aside] Is there an XML processing architecture WG?
- [Ian]
- 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.]
- [DanCon]
- Indeed, the schema WG charter was accepted 4 years ago. i.e. we have
4 years of experience since then.
- [Ian]
- 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 validation.
- 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 done.
- [DanCon]
- hmm... paul's point that we should persue the matter with the WG
1st... I could live with that.
- [Chris]
- yes, that is the principle we use as the first filter
- [Ian]
- 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.
- [Roy]
- I think TB has identified a gap in the architecture. So the real
question is who should be asked to address/fill the gap?
- [Ian]
- TB: We don't know what they think yet. I remain convinced that this
is an issue for the TAG.
- 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 syntax.
- [DaveO]
- CL said my point
- [Ian]
- 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?
- [DanCon]
- I learned quite a bit about XML schema requirements around PSVI stuff
in an xmlschema-dev
thread.
- [Ian]
- 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.
- [DanCon]
- I don't think this issue is exactly what was discussed at the xml
processing model workshop
- [Ian]
- 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).
- [Ian]
- 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."
- [TBray]
- 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
- [TBray]
- I have grave arch concerns with this assertion
- [Ian]
- 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.
- [timbl]
- Sounds as though if there is this much discussion about it, then it
may be an issue.
- [Ian]
- Action DC: Talk to XML Schema WG about
PSVI. Report to tag, who expects to decide whether to add as an issue
next week.
Source: email
from TBL. Accepted as xlinkScope-23.
Action IJ: Add to issues list.
[DaveO]
- I have some info background on xlink discussions..
- [Ian]
- TBL: I thought that "hlink" was for GUI semantics. Should RDF be used
or schema annotations?
- [Roy]
- xlink:href --> xmlns supported. Is that okay?
- [Chris]
- Yes, it implies namespace support. xlink is *not* only for
hyperlinks
- [timbl]
- 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
- [Ian]
- CL: xlink is not just for hyperlinks. It's chartered to support
replaced content (like images).
- TBL: I would include image embedding as part of (my concept of)
hypertext.
- [Ian]
- 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 through."
- DO: Why should we look at this as an issue given what the charter of
xlink says?
- [Chris]
- Using a schema "to find out where the links are", especially since it
needs a link to get the schema.
- [Ian]
- DO: Shouldn't people talk to the WGs responsible for these
technologies?
- [DanCon]
- Interesting... hyperlinking only... SVG went and used it for symbol
references, which isn't hyperlinking, is it?
- [Ian]
- 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.
- [Chris]
- Depending on whose definitions of 'hyperlink' you use
- [Ian]
- TBL: People's terminology varies (a source of confusion) and that
becomes a TAG issue.
- [DanCon]
- Again, it seems there's plenty here to justify the time of the TAG to
discuss this issue.
- [Ian]
- 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.
- [DanCon]
- Order? would the chair please ask if anybody wants this to *not* be a
TAG issue?
- [Chris]
- Agree it should be a TAG issue
- [Ian]
- 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
issue.
- 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).
- [Ian]
- PC: +1 to DO's comments.
- TB: I'm uncomfortable with history determining (mechanically) whether
we decide to accept arch issues.
- [timbl]
- The XLINK spec IMHO is made for GUI links.
- [ian_]
- 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.
- [Roy]
- xlink covers all explicit links. There are also implicit links and
externally-defined links that are not covered.
- [DanCon]
- 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 majority?
- [Chris]
- Having it added as an Issue does have some politicaly overtones,
yes
- [ian_]
- 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
valuable.
- [TBray]
- BTW I think I agree with DaveO on the appropriate use of xlink
- [Chris]
- Of course, we could always issue a finding that "there is no
problem". Issue does not equate to "clearly broken"
- [ian_]
- TBL: Just pointing out what people meant by "hypertext links" is time
well-spent.
- [DanCon]
- 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.
- [TBray]
- I don't agree that issue ==> finding
- [Norm]
- Nor do i
- [ian_]
- DO: I would drop my concern if we get clear view of what "issue
mean".
DC: Our charter says "Majority vote" to accept issues.
- [DanCon]
- 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."
- [Roy]
- Agreed
- [ian_]
- IJ: Dispositions may vary.
2.2 Findings in progress, architecture document
See also: findings.
Resolved: Publish "TAG
Finding: Consistency of Formatting Property Names, Values, and Semantics"
(formattingProperties-19).
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 finding.
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 week.
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.]
[Ian]
- 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 that.
- TBL: The hole is that you can't tell when something is a qname.
- [TBray]
- What TimBL is saying is "you could imagine a syntactic signal that
would tell you when something was a qname"
- [ian_]
- 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.
- [Norm]
- Nothing short of a new markup character can fix this
- [ian_]
- TB: Should status section say this?
- [DanCon]
- "the table of contents"?
- [ian_]
- TBL: What about TOC for "holes".
IJ: I have started to do this in the arch document: create sections
entitled "Design weakness".
ACTION DC: research the bug in the svg diagram. There are two votes to
remove the diagram (DC and TB).
.[ian_]
- 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.
- [Chris]
- The diagram could of course be *revised* not removed. People have no
issue with a correct diagram, surely
- [ian_]
- TB: So (a) nuke diagram or (b) change text to fix context.
- DC: I18N folks would like it anyway.
- [DanCon]
- 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]
- Accept suggestion
from Graham Klyne?
- Any action on dissent
from Joseph Reagle?
- [ian_]
- TB: People are worried that requiring IETF stuff will create
bureaucratic delays.
- [Chris]
- We are not requiring them to wait until its published as an RFC, just
to submit the registration, yes? (See SOAP
1.2 application).
- [Roy]
- That's my experience as well with IETF WG specs.
- [ian_]
- 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 dependency.
- 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.
- [DanCon]
- may I answer?
- [ian_]
- 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 changed.
- 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.
- [DanCon]
- 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.
- [ian_]
- PC: If this decision is in place, the XMLP WG will have to pull a
mime type registrationinto one of its normative specs.
- [DanCon]
- [several]: yes, paul.
- [ian_]
- TBL: Yes, the primary spec referenced by the registration.
- [Roy]
- i.e., the media format definition spec should contain the media type
definition forms.
- [timbl]
- XMLProtocol is about to push XMLP to last call. The spec referenced
by the registration document should include the registration document
as a part.
- [Chris]
- 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
- [ian_]
- 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 inclusion.
- [Chris]
- yes we are standing by our finding
- [ian_]
- [On comments
from Joseph Reagle.]
- [Roy]
- I read it and am standing by finding. Already rebutted.
- [ian_]
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.
- [DanCon]
- I think I understand reagle's objection well enough to clarify;
though I'd rather Roy did it. ;-)
- [ian_]
- RF: You still have to submit the original form.
- 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.
- Architecture document
- ACTION IJ 2002/03/18:
Integrate/combine one-page summaries (Revised 7 June)
- ACTION TBL 2002/05/05: Negotiate
more of IJ time for arch doc
- 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.
- RFC3023Charset-21
- ACTION CL 2002/6/03:
Write up the issue in the next day or so.
- charmodReview-17:
Confirm that this is closed.
- 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.
- If we get here: httpRange-14, namespaceDocument-8
Ian Jacobs, for TimBL
Last modified: $Date: 2006/10/20 10:59:38 $