- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 16 Dec 2002 17:31:42 -0500
- To: www-tag@w3.org
Hello,
Minutes available as HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2002/12/16-tag-summary.html
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
==========================================================
W3C | TAG | Previous: 9 Dec teleconf | Next: 6 Jan
2003 teleconf
Minutes of 16 Dec 2002 TAG teleconference
Nearby: IRC log | Teleconference details ? issues list
? www-tag archive
1. Administrative
1. Roll call: SW (Chair), TBL, DC, DO, TB, NW, RF,
PC, IJ (Scribe), Paul Gross. Absent: CL.
2. Accepted 9 Dec minutes
3. Accepted this agenda
4. Next meeting: 6 Jan 2003
5. Include title page dates in first three findings
per request from Mark Baker?
Resolved: Yes. Title page date should correspond
to the date of a TAG meeting. May include a last
revised date; indicate in status section that we
don't expect to modify in place.
6. Meeting planning: Stuart continued to work on
scheduling a meeting in January to discuss XLink.
1.1 Completed actions
1. Action SW 2002/12/09: Invite Paul Grosso to a
future meeting
2. Action SW 2002/12/09: Thanks XMLP WG
2. Technical
1. xmlProfiles-29
2. URIEquivalence-15
3. namespaceDocument-8
2.1 xmlProfiles-29
1. xmlProfiles-29
1. Action DO 2002/12/02: Talk to XMLP WG about
this new issue.
2. Action NW 2002/12/02: Talk to XML Core WG
about this new issue
3. Action NW 2002/12/09: Write up a first draft
of the TAG position
<Ian> NW: If there is a way for specs to refer
normatively to a doc that describes a subset of xml,
that would be useful. We should attempt to do this by
editorial revision of XML 1.1. So that we can produce
a spec that describes a standalone version of XML, and
have another document that says "here's what else to
do to get back full XML."
<Ian> TB: This issue is becoming more visible (see,
e.g.,sourceforge discussion).
<DanC> sourceforge tracks security exploits? ah;
security focus..
<Ian> PG: I think it's fair to say that the XML Core
WG last discussed in Feb 2002.
* DanC wondersi if Norm's comment was recorded
accurately; perhaps I should queue myself to ask
<Ian> PG: The group's sense was not being eager to
jump into a new version of XML. Glad this discussion
happening outside of XML Core for now; will make our
job easier (i.e., if the community figures out a
limited scope, it'll make the XML Core WG's job
easier). The XML Core WG is willing to work on this.
Need to figure out in which spec this would happen
(1.2? A W3C Note?)
<Ian> PG: Core WG participants have expressed opinions
from nothing -> minimal -> redoing XML right.
<Ian> TB: Launching an XML 2.0 project would be
disastrous. What's going on in XMLP is symptomatic.
Custom subsets hurting interoperability
<Ian> DO: It seems that we have a difference of
opinion about what it means to be XML. Some people
think of XML as "an XML spec", others think of XML as
XML 1.x + other things.
<Ian> TB: Anybody who will use XML will use namespaces
and likely have recourse to the infoset. It's arguable
that putting the pieces in one spec will make people's
lives easier.
<Ian> PG: I think that it would be very different
developing a minimal XML and a mechanism for
subsetting XML.
<Ian> TB: I don't like run-time profiles for XML. My
preferred approach is one hard-wired subset. xml:id is
a new feature and thus out-of-scope IMHO
<Ian> DC: I'd like any TAG finding to start "Profiles
are evil. However, in some cases they are merited...."
<PGrosso> Cf. xml:id, that is the one thing I'd have a
hard time saying cannot be considered in any "new" XML
profiles.
<TBray> slippery-slope, that's all
<Ian> TB: I think the TAG should be specific. We
should do the things that would benefit the community,
based on several years' experience.
<Ian> TBL: Consolidation of specs is a separate issue.
Are we (otherwise) just talking about removal of the
external subset?
<Ian> TB: Could be removal or a way to get rid of
billion laughs bug. (Recursive explosions in run-time
messages).
<TBray> anyhow, I'm far from convinced that xml:id is
really needed
<Ian> DO: I generally agree with TB here. In Web
Services, we have run into a problem of the notion of
doing ID attribute. Lots of Web Services vocabs have
created some kind of ID attribute.
<DanC> doc#foo doesn't work without xml:id.
<TBray> it works if you serve it as anything but
application/xml. And application/xml doesn't seem to
be useful/used in practice
<DanC> hmm..
<Ian> PG: xml:id and entities are the 2 things the XML
Core WG has told people to do in the internal subset.
We can either (1) find a way to get rid of internal
subset or (2) find a way to use safely. I have heard a
trend to no character entities.
<Zakim> PGrosso, you wanted to mention that xml:id and
entities are the 2 things the XML Core WG has told
people to do in the internal subset.
<DaveO> TB, seems like application/foo+xml that
re-used xml:id would be useful.
<TBray> to say (1) nobody else is gonna take on the
entity/char-ref problem, and (2) anybody who makes an
XML language defines an ID attribute
* DanC thinks (2) is a pretty good argument for xml:id
<Ian> NW: I am flatly opposed to the idea of changing
rules for how entities are declared. I think that this
redefining would cause lots of problem, be hard to
explain, cuase backwards compat issues. I hear people
asking for one profile: one that doesn't have an
internal subset. I would like no new features.
<TBray> camel's nose indeed
<Ian> PC to DC: Are you against us doing an XML
version that is XML*?
<Ian> DC: I want the cost of profiling acknowledged
every time it's done.
<Ian> PC: I am favorable to the idea of creating an
XML-SW spec (or something like it). I ack DC's point
about cost of profiles.
<PGrosso> What is the advantage of combining specs at
this point? It's too late to make the spec easier to
read for implementors.
<Ian> TB: XML-SW has fewer options than XML 1.0.
Nobody in the world is going to take on the job of
defining a new way of defining character entities (or
other kinds).
<Norm> We can't get rid of existing processors, so the
fact that the subset is smaller doesn't mean there's
fewer options; there can only be more options
<Ian> TB: On xml:id - every xml language I know of has
an ID attribute.
<PGrosso> Tim, does that mean that we should do it
(define entities) or not do it?
<Ian> TB: In almost every case, it happens to be named
"id". IDs won't go away.
<Norm> If you want an ID, use an internal subset or a
schema language.
<Ian> TB: xml:id is a plausible idea, but I agree with
NW - no new features.
<Roy> I don't see how anyone could consider "entities
must not be parsed or expanded inside entity
declarations" a difficult to understand requirement. I
am seriously considering asking that Xerces implement
that in spite of the XML standard, because in this
case XML is broken for all implementations. Unsafe
code is never worthwhile outside of weaponry, and even
then only when it is designed to be unsafe.
<DanC> ooh... yes, fix xpointer so that #bar means the
xpath expression @id='bar'
<Ian> RF: I think it's a bug fix to XML : don't expand
entities to be expanded in the declaration section.
<Ian> NW: There are cases when cross referencing
entities is a good / useful thing.
<DanC> yeah; it would change the meaning of documents
that are fairly widely deployed. bad news.
<Ian> TB: The cost of doing this in XMLP and other
applications is unacceptably high. A profile would not
make XML 1.0 go away.
<Ian> NW: I'm happier with an onion that has neither
references to external or internal subsets. And built
other XML versions on top of that. If you want what
XML 1.0 does, use XML 1.0; If you want something else
use this other [not yet defined] spec... We can define
XML 1.1 as two specs (a core with no decls and a full
1.1 that has the rest).
<Ian> TB: version attribute.
<Ian> NW: This can't be accomplished without revving
the version number in XML 1.0 (e.g., 1.2a, 1.2b....)
Or one could add a pseudo-attrib to the XML
declaration.
<Ian> TB: A profile would be subject to AC approval,
right?
* tim-lex didn't see why you had to label the subset
with xml 1.0
<Ian> PG: The XML Core WG should ask the AC to make
clearer that we should pursue this (charter language
insufficient).
<Ian> TB: We should document what we feel to be
cost-effective and send to the AC.
<Ian> DO: I'm interested in the TAG talking to the AC
(e.g., about pursuing work).
<Ian> PC: What's the relationship of this to Web
architecture?
<Ian> NW: Before we ask the AC to do anything; please
wait until I finish my action item and that the TAG
agree to precisely what we want to do.
<Ian> DC: It's been suggested that our arch doc say
"use xml for doc formats." One reason is that it has a
self-similar syntax. DTDs make it a lot self-similar,
however. There is a connection to architecture:
self-similar syntax; minimalism.
<Ian> TBL: The Arch Doc says it's a good thing to
build networks by using messages; and a good idea to
use xml to do that. As it stands, there's an obvious
problem (due to denial of service attacks).
<TBray> DO: message to AC from TAG pointing out that
we've got a problem here. Going to a subset/profile
architecture helps with the architecture
<TBray> DO thinks the AC will find this compelling
<TBray> SW: proposal to wait for Norm's action and
consider going to AC thereafter
<Norm> My point was that we should agree amongst
ourselves, in writing, about what we're asking the AC
to do
<TBray> DO: emerging conensus that this is a good
thing
<TBray> Norm: will get this to us this week
<TBray> PG: would be useful, when handing to AC & then
core...Indication as to what we might call this (1.x,
2.x) and schedule. Could Norm include suggestion for
implementation
<Ian> IJ: What form would communication take with AC?
<Ian> DC: I think this would take the form of an
Activity Proposal.
<Ian> SW: Thanks to PG for joining us!
2.2 URIEquivalence-15
1. Status of URIEquivalence-15, IRIEverywhere-27.
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. Action MD 2002/11/18: Write up text about
IRIEverywhere-27 for spec writers to include
in their spec.
2. Action CL 2002/11/18: Write up finding for
IRIEverywhere-27 (from TB and TBL, a/b/c), to
include MD's text.
3. TB's "How to Compare Uniform Resource
Identifiers" draft finding.
<Ian> TB: The hard problem this reveals is that a
close reading of 2396 makes it clear that you can't
tell whether %2a means the same other thing %2a in a
different encoding. Will this be fixed, RF?
<Ian> RF: I'll try to clarify what it means. I have
some comments on uri-comp-2. I'll send those in today.
<Ian> DC: You compare URIs with strcmp. It doesn't
matter what the URI is. Server gets to choose what the
URI string is. Only the server knows what %61 means.
<Ian> TB: I have an example that shows strcmp is
insufficient.
<Ian> [PC leaves]
<Ian> * http://dir/a
<Ian> * http://dir/%61
<Ian> DC: Those are strings of different lengths;
different URIs. Practice of Web browsers is heuristic.
<Ian> TB: False negs are built into the system. But
false positives should be avoided.
<Ian> DC: /index.html and / might be considered equal
by google, and that could be a false positive.
<Ian> [Discussion of RFC2396 clarification]
<Ian> RF: Schemes don't define what's reserved in each
path since that is not standardized generally.
Generally the specs shouldn't require things that the
software doesn't implement. Within namespaces, there
are chars that are used in a reserved way, that are
not part of the generic set of reserved characters.
Client is not allowed to %-escape something that isn't
already in the form of data. Client can't take an
existing URI and decode it without loss of
information.
<Ian> TB: I think the action item is to watch for
feedback on this finding. In a week or so, I'll turn
over to IJ to beautify.
2.3 namespaceDocument-8
1. namespaceDocument-8
1. Action NW 2002/11/18: Take a stab at
indicating pros and cons for the various
RDDL/RDF/Xlink designs arising from TB's RDDL
challenge.
1. RDDL Proposal from Tim Bray.
2. RDDL Proposal from Chris Wilper
3. RDDL Proposal from TBL
4. RDDL Proposal from Jonathan Borden
<DanC> # Re: The RDDL challenge Tim Berners-Lee (Mon,
Dec 09 2002)
http://lists.w3.org/Archives/Public/www-tag/2002Dec/01
30.html
<Ian> DC: As I said last week, I will oppose anything
that says that putting an XML Schema at end of
namespace URI is broken. I think that RDDL is a
distraction. It suggests that there's nothing that's
ok to put there now.
<Ian> TB: Good exchange between DC and me on www-tag
this week.
<Ian> DC: W3C has used RDF, Schema, and XHTML to
document a namespace.
<DanC> # what's wrong with using XML Schema/HTML/RDF
to document namespaces? Dan Connolly (Mon, Dec 09
2002)
http://lists.w3.org/Archives/Public/www-tag/2002Dec/01
23.html
<Ian> DC: XML Schema and RDF Schema are ok by me.
<TBray> thread starts at
http://lists.w3.org/Archives/Public/www-tag/2002Dec/01
23.html
<Ian> DC: There is no format that I would advocate for
all uses
<Ian> DO: What are the criteria that you would use to
decide what format to use?
<Ian> DC: If you are doing an RDF vocabulary, using an
RDF schema would be useful.
<DanC> RDF schemas with CSS work pretty well, in
recent experience. RDF schemas can even meet the "I
wanna look at it in my browser" goal.
<Ian> TBL: I think that we need to realize that
different applications will have different sorts of
needs. You may not want an indirection in all cases. I
think it's reasonable to write down some best
practices. I think RDDL is reasonable, but I'd rather
RDDL be yet another format.
<Ian> DO: I've heard one criterion - if doing RDF, use
RDF assertions for namespace doc. Seems like we may
cause more confusion. I think this makes the problem
worse by allowing multiple different types of formats
for namespace docs.
<Ian> DC: Nobody has written the last work on how to
choose a programming language. Why is this different?
<Ian> TB: A really important use case is someone
wishing to find documentation the first time they
encounter a namespace. Schema annotations don't work
for me; I don't have a schema processor.
<Ian> TBL: An XML schema should have proper
descriptions; but they may not be viewed by people.
RDF + CSS can provide human-readable and
machine-readable solution.
<Ian> DC: Is CSS considered exotic machinery? See info
about syndicating W3C home page. This is an example of
RDF + CSS.
<Ian> TB: If you can do that, that's a good outcome.
Constraints: (1) Need to be able to include N links to
other resources and (2) Need to be able to point a
browser at it for human-readable descriptions.
<Ian> DO: In my opinion, if we don't standardize on a
format, I want to return to the position that you
SHOULD NOT put something at the end of a namespace
URI.
<Ian> NW: The namespace spec just says it's not a goal
to put something there.
<Ian> DC: I'm fine with RDDL; just don't say there's
anything wrong with an XML schema there. I still think
that TB + NW to write up options is a good idea.
<Ian> TB: I think XML schema is a bad choice since
lots of machinery is required.
<Ian> DC: It's easy to find annotations; you don't
need a schema processor.
<Ian> IJ: I think that I hear agreement about the
desirability of TB's constraints, that there are
different formats for achieving goals in different
cases. I hear DO saying that N formats will not
satisfy him.
<Ian> TBL: You have to assume that on top of schemas,
or html, there are conventions for including
additional info. You have to give people the benefit
of the doubt; that problems can be addressed. You need
to assume certain conventions (e.g., for putting an
RDF schema inside an XML schema, etc.).
<Ian> TB: I believe we have enough input to do so.
<Ian> SW: I think we are awaiting NW's output in order
to proceed.
2.4 Postponed
1. binaryXML-30
1. Action CL 2002/12/02: Write up problem
statement about binary XML; send to www-tag.
2. fragmentInXML-28 : Use of fragment identifiers in
XML.
3. xlinkScope-23 (5 minutes)
1. Action SW 2002/11/18: Organize a
special-interest teleconf for discussion of
this issue on linking. Pending; see email
from SW (TAG-only).
2. Completed action SW 2002/12/09: Contact the
Hypertext Coordination group, Vincent Quint
chair, as part of organizing linking meeting.
2.5 Findings in progress, architecture document
See also: findings.
1. Findings in progress:
1. deepLinking-25
1. Action TB 2002/09/09: Revise "Deep
Linking" in light of 9 Sep minutes.
2. URIEquivalence-15
1. TB's "How to Compare Uniform Resource
Identifiers" draft finding.
2. 6 Dec 2002 Editor's Draft of Arch Doc (new):
1. Action CL 2002/09/25: Redraft section 3 based
on resolutions of 18 Nov 2002 ftf meeting.
2. Complete review of TBs proposed principles
CP9, CP10 and CP11
_________________________________________________
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2002/12/16 22:26:35 $
Received on Monday, 16 December 2002 17:31:48 UTC