IRC log of #tagmem on 2002-02-12
Note: This log was built by appending two logs. Some Member-only
information in the original log has been replaced by a public equivalent.
There have also been minor fixes to this log (e.g., speaker name
repaired).
Timestamps below are in Boston time.
[08:35:39]
--> Ian (~ian@tux.w3.org) has joined #tagmem
[08:35:49]
--- Ian has changed the topic to: TAG face-to-face meeting
[09:54:29]
--> PaulC (~pcotton@tide109.microsoft.com) has joined #tagmem
[09:54:29]
<PaulC> We are ready in Redmond but are
waiting for our AV technician to help us make the link.
[09:58:37]
--- Ian has changed the topic to: TAG face-to-face meeting.
[09:58:53]
<PaulC> We are about to connect. Are you
ready?
[09:59:00]
--- Ian has changed the topic to: TAG face-to-face meeting. Agenda:
http://www.w3.org/2002/02/12-tag
[10:00:21]
<PaulC> Are you ready at MIT?
[10:01:48]
<Ian> We can't hear you yet.
[10:02:05]
<PaulC> We are working on the audio end. We
can hear you.
[10:03:13]
<Ian> Yes
[10:03:16]
<Ian> we can hera.
[10:03:49]
<Ian> At MIT: Norm, Stuart, TimBL, Ian
[10:04:00]
<Ian> In Redmond: Tim Bray, Paul, David
[10:04:07]
<PaulC> At Redmond: Paul, TimB and
DavidO.
[10:04:31]
<Ian> Regrets: Chris, DanC, Roy.
[10:07:04]
--> TimBL (~timbl@tux.w3.org) has joined #tagmem
[10:08:02]
<TimBL> ACTION Ian check out what happens
if one were to change ones job while on TAG
[10:09:31]
<Ian> Action canceled since text in Process
Doc found.
[10:09:33]
<Ian> Agenda:
[10:09:38]
<Ian> http://www.w3.org/2002/02/12-tag
[10:09:56]
<PaulC> The appropriate info is in 1.4.1
Technical Architecture Group participation.
[10:10:17]
<PaulC> "A TAG participant may resign,
change affiliations, or fail to remain in good standing. When any one of
these three occurs, the Director may replace appointed participants with a
new appointment, or may declare an elected participant's seat to be
vacant."
[10:10:30]
* Ian wonders whether "may" is a bug or a
feature....
[10:10:50]
--- You are now known as IanTAG-MI
[10:11:02]
<IanTAG-MI>
------------------------------------------------------------------------
[10:11:20]
<IanTAG-MI> Strawman categorization of
architectural areas
[10:11:27]
<IanTAG-MI>
http://www.w3.org/2001/tag/doc/toc
[10:11:50]
<IanTAG-MI> TB: Good first cut.
[10:12:10]
<IanTAG-MI> PC: Why organized this way?
[10:12:36]
<IanTAG-MI> TBL: I started off with the
question "What does a (MIME type, bits) pair mean?
[10:12:36]
<IanTAG-MI> "
[10:12:52]
--> Norm (~ndw@24-6-202.wireless.lcs.mit.edu) has joined #tagmem
[10:13:22]
* IanTAG-MI plays with camera...
[10:13:41]
--> Stuart (~skw@phobos.hpl.hp.com) has joined #tagmem
[10:14:01]
<IanTAG-MI> TBL: The Web (in the abstract
place) works in a loop - a document has a URI, that causes you to do some
protocols, you get another document, and that may have more URIs...
[10:14:25]
<Norm> FYI, attempts to get the agenda fail
due to authorization problems
[10:14:57]
<IanTAG-MI> TBL: Static model of the Web:
the simplification of life where we talk about something having a value or
having a meaning. We ignore the changes that occur in the background.
[10:15:49]
<IanTAG-MI> TBL: Notion of "Rest"
[10:16:49]
<IanTAG-MI> PC: At what level do you
introduce other protocols than HTTP?
[10:17:17]
* IanTAG-MI flips AC; agenda should now be
available.
[10:17:23]
<IanTAG-MI> (Wait for mirrors to kick
it...)
[10:17:43]
* IanTAG-MI missed reply from TBL.
[10:18:42]
* Norm confirms Agenda availble
[10:18:47]
<Norm> s/availble/available/
[10:19:11]
<IanTAG-MI> DO: What is the scope of Web
Architecture (w.r.t. other protocols)?
[10:19:22]
<IanTAG-MI> TBL: A clean cut is pieces
1-2-3. Until Web Services.
[10:19:52]
<IanTAG-MI> TBL: We can say that some
things are not part of this (e.g., DNS). But if someone sends a message by
SMTP, that doesn't mean that they sneak past the architecture.
[10:20:07]
<IanTAG-MI> DO: When we talk about the Web,
we generally talk about HTML/XML things, URIs, and a variety of protocols.
[10:20:16]
<IanTAG-MI> TBL: But that doesn't cover Web
services....
[10:20:26]
<IanTAG-MI> DO: I would include Web
services
[10:21:10]
<PaulC> Coffee is made in Redmond.
[10:21:19]
<IanTAG-MI> TBL: HTTP was successful, but
the Web has primarily been URIs. Other schemes have worked (e.g., mailto,
ftp, etc.).
[10:21:46]
<IanTAG-MI> DO: It'd be useful to be able
to say "When we talk about Web arch, we are talking about X, Y, Z...)"
[10:22:09]
<IanTAG-MI> TB: What is a URI could be
rephrased "What is a resource?"
[10:22:33]
<IanTAG-MI> TBL: RDF uses term "resource"
in a different way than URI.
[10:22:44]
<IanTAG-MI> TBL: Difference between URI and
URI reference.
[10:23:08]
--> Zakim (~rrs-bridg@tux.w3.org) has joined #tagmem
[10:25:04]
<IanTAG-MI> DO: A URI is for a complete
resource. A fragment ID refers to a fragment of the resource.
[10:25:22]
<IanTAG-MI> TBL: foo.rdf#tree, in RDF
terms, identifies a resource, but this is not a resource in the URI sense.
[10:25:28]
<IanTAG-MI> TB: So RDF is arguably
incorrect.
[10:25:34]
<IanTAG-MI> ...in its use of the term.
[10:25:49]
<IanTAG-MI> TBL: Yes. We could ask the RDF
folks to change it. In DAML, they use "Thing".
[10:26:50]
<IanTAG-MI> DO: We might also want to say
what we can do with a URI.
[10:27:18]
<IanTAG-MI> ....e.g., a URI that identifies
a concept rather than a resource. And you expect that the URI won't be
dereferenced.
[10:27:26]
* IanTAG-MI suggests we get past the name/address
discussion...
[10:27:55]
<IanTAG-MI> TB: It would be useful to
include in this document the summary of the difference between "resource" as
used in RDF and URIs.
[10:31:01]
<IanTAG-MI> TB: Yes, people use URIs to
name things. Here are good reasons to do so. And you have the possibility of
putting useful information at the end of a URI.
[10:31:17]
<IanTAG-MI> DO: There has been other talk
in the past about URCs and URNs....
[10:31:39]
<IanTAG-MI> ....a lot of people are using
URIs to define characteristics and names. We should state clearly how we
believe URis should be used to do those things.
[10:32:14]
<IanTAG-MI> SW: Do we have expectations
that HTTP URIs used for naming be dereferentiable?
[10:32:29]
<IanTAG-MI> DO: We should say that the http
scheme gives no expectation about whether it's to be dereferentiable.
[10:32:38]
<IanTAG-MI> DO: HTTP in this context does
not mean location.
[10:32:53]
<IanTAG-MI> NW: I know that's true, and
that I should just give up, but this bothers me. This is not the user's
expectation.
[10:33:10]
<IanTAG-MI> ...People on the street think
that things after "http:" are Web pages that can be retrieved.
[10:33:31]
<IanTAG-MI> TBL: I think we should say that
fundamentally they are names - you don't change them, for example (read: Cool
URIs don't change)
[10:34:15]
<IanTAG-MI> TB: The empirical evidence is
on NW's side, however.
[10:34:36]
<IanTAG-MI> PC: NW's example is a human
agent. People don't want computers to necessarily dereference some URIs.
[10:35:01]
<IanTAG-MI> ...NW only gave part of the
story - people used to typing URIs and getting information back.
[10:35:19]
<IanTAG-MI> ...computer programs don't want
to have to dereference URIs...
[10:35:28]
<IanTAG-MI> NW: Why are these all in the
same bucket?
[10:36:30]
<IanTAG-MI> TBL: The answer to "Why use
HTTP for a namespace?" is that most of the time, we expect the browser to
dispatch on it. However, there is no hard boundary between that case and the
case of SVG3, where the browser doesn't recognize ".svg3" but dereferences
the URI and can learn something in doing so.
[10:36:53]
<IanTAG-MI> ...it's useful to build a
generic machine, for example, that will validate your site, and then boot
itself....
[10:37:17]
<IanTAG-MI> TBL: People should build
software that doesn't necessarily follow http URIs.
[10:37:47]
<IanTAG-MI> SW: Isn't part of the reason is
the decentralized authority of the namespace?
[10:37:55]
<IanTAG-MI> ...I don't know how you create
a URN...
[10:38:44]
<IanTAG-MI> TB: This touches on our issue
8. I might want to assert:
[10:39:02]
<IanTAG-MI> - If you want to use a URI for
a namespace, it's almost always good to put something there.
[10:39:13]
<IanTAG-MI> TBL: I agree. This is the
Web.
[10:39:23]
<IanTAG-MI> ...people haven't understood
how it's useful yet.
[10:39:59]
<IanTAG-MI> ...later on, as we get more
sophisticated, and we can put metadata at the end of the URI, that's a huge
win. Or to put software drivers at the end of the URI; that's a huge win.
[10:40:18]
<IanTAG-MI> ...in the future, the path
where you look up something in real time will be very useful.
[10:40:53]
<IanTAG-MI> ...in the future, there will be
more competing vocabularies (formats) and the dynamic lookup case will be
useful.
[10:41:14]
<IanTAG-MI> ...but there will be cases
where people will not want or need to dereference.
[10:41:56]
<IanTAG-MI> DO: I think about URIs as data types (or a representation
thereof). We want to have names, characteristics, and locations. It turns out
that URIs work well for identifying a bunc of those.
Timestamps below are in UTC.
- 15:46:54 [IanTAG-MI]
- TB: The person most likely to run across a URI is some sort of
technical person. Software may not have any confusion about whether
it's using a URI as a hash key or as something to dereference.
- 15:47:28 [IanTAG-MI]
- TB: I would say that the architectural principle is that:
empirically, URIs work well as names in the Web arch. It's good
practice, when you do this, to put some explanatory material at the end
of the URI (and this may change as we get smarter).
- 15:47:45 [IanTAG-MI]
- PC: But that the URI can also be used on its own (on the
airplane).
- 15:48:10 [IanTAG-MI]
- PC: People I talk to only want it to be clear that people don't have
to dereference a URI if they don't want to.
- 15:48:26 [DanC]
- DanC has joined #tagmem
- 15:48:38 [Norm]
- Morning Dan
- 15:48:49 [IanTAG-MI]
- PC: 99% of the processing of a scheme is done by the schema agent.
But if I read as a human and come across a URI, I may want to follow
it.
- 15:50:52 [IanTAG-MI]
- Resolved points to include in document:
- 15:51:00 [IanTAG-MI]
- 1) Use URIs to name when in Web context.
- 15:51:08 [IanTAG-MI]
- 2) Should include explanatory material at end of URI
- 15:51:32 [IanTAG-MI]
- 3) Software is not required to deference a URI when processing
it.
- 15:51:58 [IanTAG-MI]
- TBL: URIs are the lynchpin of the Web arch, so this is document
"1.1".
- 15:52:19 [DanC]
- 2 relevant situations come to mind: the http://www.w3.org/XML/1998/namespace
and the /2001/XMLSchema namespace (together), and (2) use of URIs in
WebOnt, specifically to refer to XML Schema components
- 15:52:56 [IanTAG-MI]
- Action PC: Write down this summary of using URIs.
- 15:53:31 [PaulC]
- Architecture of wEb is based on unamibigously defining things in
plain text using URIs.
- 15:53:45 [IanTAG-MI]
- TBL: Also check out URIs - http://www.w3.org/DesignIssues/Axioms.html
- 15:54:16 [DanC]
- let's please address the real-and-present-danger, OK? i.e. actual
namespaces W3C defines, and whether to serve XHTML, RDDL, XML Schema,
etc. at the end.
- 15:54:22 [TimBL]
- s/plain text/by idenifiers inthe same globale space/
- 15:55:07 [TimBL]
- Dan, are you on the bridge?
- 15:55:11 [IanTAG-MI]
- TB: That's our issue 8.
- 15:55:13 [DanC]
- No, I'm in another telcon
- 15:55:23 [PaulC]
- To Dan: That is Issue 8. What we talking about now is whether the URI
must be dereferenceable.
- 15:55:29 [IanTAG-MI]
- DO: In writing the arch document, we might call this "naming and
identifying".
- 15:55:42 [IanTAG-MI]
- DO: We can talk about the functionality that the data type gives
us.
- 15:55:51 [PaulC]
- Most of has have agreed that it CAN be dereferenceable but you cannot
assume a computer agent will dereference it.
- 15:56:15 [IanTAG-MI]
- TBL: We also need to talk about what URIs don't give you (e.g., some
schemes don't allow you to deference, or md5 has a special relation to
bits, etc.)
- 15:56:24 [Norm]
- <aside>Are there any widely used cases of URIs that are not
regularly dereferenced other than Namespace Names?
- 15:56:36 [DanC]
- I recently attempted to debunk this "xmlns things are just names; why
is xsv looking them up?" myth: http://lists.w3.org/Archives/Public/xmlschema-dev/2002Feb/0054.html
- 15:57:00 [IanTAG-MI]
- DO: I think arch documents should be built such that the heading is
the functionality of what we're trying to achieve.
- 15:57:06 [IanTAG-MI]
- ...URIs are our solution to the problem.
- 15:57:38 [IanTAG-MI]
- I once wrote a description of Web architecture based on
functionalities: you identify, retrieve, send, comment on, build,
destroy, etc.
- 15:58:49 [IanTAG-MI]
- PC: We need to make sure that DanC is onboard with our summary.
- 16:00:22 [IanTAG-MI]
- NW paraphrasing: If the rate of 404s goes way up, people will be
disappointed.
- 16:00:30 [IanTAG-MI]
- TB: We address this by saying authors should put something at end of
URIs.
- 16:00:42 [IanTAG-MI]
- TBL: On the thread of namespaces = punctuation.
- 16:01:04 [IanTAG-MI]
- http://lists.w3.org/Archives/Public/www-tag/2002Feb/0022.html
- 16:02:51 [IanTAG-MI]
- Patrick's conclusion:
- 16:02:56 [IanTAG-MI]
- "We will continue to have no end of trouble and confusion
- 16:02:56 [IanTAG-MI]
- if we continue to allow folks to think that namespace URIs
- 16:02:56 [IanTAG-MI]
- are *real* URIs. They're not. They're just punctuation.
- 16:02:56 [IanTAG-MI]
- "
- 16:03:59 [IanTAG-MI]
- zakim, please list conferences
- 16:04:00 [TimBL]
- Zakim, list
- 16:04:00 [Zakim]
- I see W3C_Team(MIT Site)10:00AM, VB_VBWG()10:00AM, TAG_TAG
f2f()10:00AM
- 16:04:01 [Zakim]
- I see W3C_Team(MIT Site)10:00AM, VB_VBWG()10:00AM, TAG_TAG
f2f()10:00AM
- 16:04:11 [IanTAG-MI]
- zakim, this is TAG_TAGftf
- 16:04:12 [Zakim]
- sorry, IanTAG-MI, I do not see a conference named 'TAG_TAGftf'
- 16:04:14 [TimBL]
- Zakim, this is TAG
- 16:04:15 [Zakim]
- ok, TimBL
- 16:04:15 [IanTAG-MI]
- zakim, this is TAG_TAGf2f
- 16:04:16 [Zakim]
- sorry, IanTAG-MI, I do not see a conference named 'TAG_TAGf2f'
- 16:04:33 [IanTAG-MI]
- zakim, MIT holds Stuart, TimBL, IanTAG-MI
- 16:04:34 [Zakim]
- sorry, IanTAG-MI, I do not recognize a party named 'MIT'
- 16:04:51 [TimBL]
- Zakim, who's here?
- 16:04:52 [Zakim]
- I notice TAG_TAG f2f()10:00AM has restarted
- 16:04:53 [Zakim]
- I see MIT video room
- 16:05:24 [TimBL]
- Zakim, "MIT video room" is really MIT
- 16:05:25 [Zakim]
- I don't understand '"MIT video room" is really MIT', TimBL. Try /msg
Zakim help
- 16:05:35 [TimBL]
- Zakim, MIT video room is really MIT
- 16:05:36 [Zakim]
- I don't understand 'MIT video room is really MIT', TimBL. Try /msg
Zakim help
- 16:06:00 [TimBL]
- Zakim, MIT is really MIT
- 16:06:01 [Zakim]
- +MIT; got it
- 16:06:10 [TimBL]
- Zakim, MIT holds Ian
- 16:06:11 [Zakim]
- +Ian; got it
- 16:06:20 [TimBL]
- Zakim, MIT also holds TimBL
- 16:06:21 [Zakim]
- +TimBL; got it
- 16:06:23 [TimBL]
- Zakim, MIT also holds Norm
- 16:06:24 [Zakim]
- +Norm; got it
- 16:06:31 [TimBL]
- Zakim, MIT also holds Stu
- 16:06:32 [Zakim]
- +Stu; got it
- 16:12:19 [IanTAG-MI]
- TB: Let's grant that it's desirable to address the notion of an
element or attribute. Suppose that I have 3 or four different schemes
and style sheets for a given language. Not sure for me what's to be
addressed.
- 16:12:28 [IanTAG-MI]
- NW: There are 2 different DTDs for HTML.
- 16:13:11 [TimBL]
- We areflaging issues as we go by
- 16:13:34 [IanTAG-MI]
- TB: Given a namespace and an element type and a schema (and only
that), it would be great to be able to get the definition of an element
whatever schema is used.
- 16:13:44 [IanTAG-MI]
- TBL: The URI of the element type is a useful thing.
- 16:14:41 [IanTAG-MI]
- TBL: If someone else builds a language that talks about XML and
doesn't use these URIs (to elements), that's their issue. For W3C specs
(at least), we'd like to be able to make RDF statmeents about element
types.
- 16:14:56 [IanTAG-MI]
- TB: It would be nice if RDF and XML schemas were consistent.
- 16:15:05 [IanTAG-MI]
- TBL: Consistent in what way?
- 16:15:37 [IanTAG-MI]
- TB: Our issue 8 asserts that there's an inconsistency.
- 16:15:49 [IanTAG-MI]
- TBL: That's about the mapping of qnames to URIs (XML Schema doesn't,
and RDF does).
- 16:16:00 [PaulC]
- My other requirement is that XQuery needs to refer to data types
defined by XML Schema and since all types in XML Schema are not
referenceable this is hard.
- 16:16:12 [DanC]
- please let's not refer to issues by number alone. Some WGs have long
threads on "issue 280" or whatever. It becomes a priesthood. bad
news.
- 16:16:21 [DanC]
- rdfmsQnameUriMapping-6
- 16:17:13 [IanTAG-MI]
- PC: If there were a mechanism for describing what datatypes a
language is defining, then XQuery would be able to use URIs to refer to
any of those data types.
- 16:17:27 [IanTAG-MI]
- ...that would allow query to build on a common architecture.
- 16:17:33 [IanTAG-MI]
- TBL: That's the case for RDF, too.
- 16:17:59 [DanC]
- IanTAG-MI, pls link this from issue rdfmsQnameUriMapping-6: * URIs
for terms: motivation [was: Requirements Document] Dan Connolly (Fri,
Feb 08 2002) http://lists.w3.org/Archives/Public/www-webont-wg/2002Feb/0028.html
- 16:18:25 [IanTAG-MI]
- TBL: For every data type you create, you should be able to refer to
with a URI.
- 16:18:38 [IanTAG-MI]
- q+ NW
- 16:18:59 [IanTAG-MI]
- DO: I don't see in the arch toc yet the notion of type definition of
things.
- 16:19:03 [IanTAG-MI]
- TBL: Yes, that would be further on.
- 16:19:16 [IanTAG-MI]
- DO: There needs to be a type definition section.
- 16:19:44 [DanC]
- has the overall structure of tag/doc/toc been endorsed? I could live
with it, but I've got significant investment in
/DesignIssues/Architecture and /DesignIssues/Axioms
- 16:19:54 [IanTAG-MI]
- NW: Do we need URIs to refer to types independent of the schemas used
to define those types?
- 16:20:02 [IanTAG-MI]
- PC: This ground has been covered many times before.
- 16:21:04 [TimBL]
- http://lists.w3.org/Archives/Public/www-webont-wg/2002Feb/0028.html
is hereby homework
- 16:21:14 [DanC]
- er... I'm confused. I thought agenda item 1 was: proposed: to adopt
tag/doc/toc as our outline. That's not what we're talking about?
- 16:21:29 [IanTAG-MI]
- q+ DanC
- 16:22:25 [IanTAG-MI]
- Action TBL: Add a section on "datatypes" to the TAG toc.
- 16:23:05 [PaulC]
- Suggestion: When the TAG discusses an issue like issue-6 it might be
wise to have some "expert witnesses" present to help us understand the
history and the rationale for the current situation.
- 16:23:10 [TimBL]
- Dan, in answer to your q - yes, we are going thrr the document TOC.
We are making sure we haven't skipped issues as we go ... and we are
adding stuff
- 16:24:09 [IanTAG-MI]
- TB: I disagree with DanC - the other /DesignIssues/* documents
contain valuable stuff, but I prefer /doc/toc organization.
- 16:24:23 [IanTAG-MI]
- ...also I think that TAG should start with tabula rasa and answer
arch issues in order of priority.
- 16:24:26 [PaulC]
- I think the TAG needs to meet its goals of writing down the
Architecture and having a TOC like this is a good start.
- 16:24:27 [IanTAG-MI]
- DO: I concur.
- 16:25:31 [IanTAG-MI]
- TBL: I'd be interested in knowing when /DesignIssues/* does not
include things that we are talking about.
- 16:25:45 [IanTAG-MI]
- -----------------------------------------------
- 16:26:23 [IanTAG-MI]
- Moving on to second part of http://www.w3.org/2001/tag/doc/toc
- 16:26:27 [IanTAG-MI]
- What does a (MIME type, bits) pair mean?
- 16:26:27 [IanTAG-MI]
- 1.
- 16:27:23 [IanTAG-MI]
- TBL: This is a deliberate statement - you can put other headers in a
message, but MIME type + bits is necessary and sufficient to tell you
what something means.
- 16:28:14 [IanTAG-MI]
- TB: Issues w3cMediaType-1, customMediaType-2, nsMediaType-3 relevant
here.
- 16:28:21 [DanC]
- umm... Content-Transfer-Encoding: gzip
- 16:28:43 [IanTAG-MI]
- PC: As we're writing things down, we need to correlate our tactical
issues with our writings.
- 16:28:57 [DanC]
- please read "all the Content-* headers + bits" for "MIME type +
bits"
- 16:30:05 [TimBL]
- Oh, really? I had represented you as saying that mime+bits was nec
and sufficient
- 16:30:52 [IanTAG-MI]
- TBL: Does anybody object to this approach to this way of working - we
ensure that every tactical issue has a place in the architecture
document (where explained)?
- 16:31:08 [IanTAG-MI]
- No objections from anyone (DanC hasn't commented yet).
- 16:31:23 [IanTAG-MI]
- TB: As we address issues, part of the discussion should be "Where
does this go in the arch document?"
- 16:31:24 [TimBL]
- forall i { i a issue } -> { [ a section] dealswith i }.
- 16:32:12 [IanTAG-MI]
- IJ: For the record, I expect there to be N documents. I'm happy to
refer to the set as "The Architecture Document".
- 16:32:53 [IanTAG-MI]
- TBL: I suggest that perhaps instead of independent findings
documents, we insert text in a given section of the arch document.
- 16:33:17 [IanTAG-MI]
- PC: One concern I have for the TAG is revisiting turf people have
visited before. This is to be expected for some time as we ramp up.
- 16:33:58 [IanTAG-MI]
- ...however, when a novice reads the arch of the Web document, there
should be a pointer back to the issue and discussion of it (so people
can understand context and how conclusions were drawn).
- 16:34:06 [DanC]
- ok, I'm off the other call; next telcon is in 2.5hrs. should I join
now? or do you want me to join later in the day? or maybe tomorrow?
- 16:34:09 [IanTAG-MI]
- PC: Collaborative use of the Web.
- 16:34:20 [IanTAG-MI]
- DanC, one-day meeting.
- 16:34:26 [DanC]
- oops
- 16:34:29 [DanC]
- really?
- 16:34:32 [IanTAG-MI]
- Yep
- 16:34:34 [TimBL]
- DanC, that would be great
- 16:34:42 [DanC]
- what would be great?
- 16:34:51 [IanTAG-MI]
- What, a chicken?
- 16:35:04 [TimBL]
- The TAG meeting is 10:00-19:00 ET 09:00-18:00 CT
- 16:35:25 [IanTAG-MI]
- PC: We should be prepared to invite experts on a given topic when we
plan to discuss it.
- 16:35:47 [DanC]
- I'm willing to join for an hour or so. please pick which hour.
- 16:36:49 [IanTAG-MI]
- PC: We cannot write down arch principles that ignore history.
- 16:36:52 [TimBL]
- This hour, I guess. It is the safest, and you seem to have some
input
- 16:37:31 [DanC]
- Zakim, what's the passcode?
- 16:37:32 [Zakim]
- the conference code is 8241, DanC
- 16:37:33 [IanTAG-MI]
- Dan, cod is 8241
- 16:37:42 [IanTAG-MI]
- wow, zakim beat me. :)
- 16:37:50 [TimBL]
- Things to hang off the TOC: - documents - issues -- holes in the
arch
- 16:38:14 [IanTAG-MI]
- TB: I'd like to register a concern for the record that DanC's
workload is such that he can only dedicate one hour to our first ftf
meeting.
- 16:38:30 [DanC]
- agenda request: WG training between now and when we have an
architecture document.
- 16:38:36 [Zakim]
- +DanC
- 16:39:19 [DanC]
- I offered my regrets and they were accepted, no?
- 16:39:56 [IanTAG-MI]
- q+ DanC
- 16:40:09 [IanTAG-MI]
- TB: I like almost all of section 2 but for 2.3 (on generic xml).
- 16:40:32 [IanTAG-MI]
- TB: I'm less convinced that service generic XML is a good idea when
you can avoid doing it.
- 16:40:50 [IanTAG-MI]
- TB: Character encoding, etc. don't just apply to generic XML, they
apply to any XML.
- 16:41:07 [IanTAG-MI]
- TB: XML Digital Signature also arises in RDF and other places than
generic XML.
- 16:41:23 [IanTAG-MI]
- TBL: I should separate XML and generic XML (meaning "unlabled by more
specific mime type").;
- 16:41:42 [IanTAG-MI]
- q+ DO
- 16:41:45 [DanC]
- "XML Digital Signature has some real architectural problems" <-- I
thought i heard Tim Bray say that; I'd like him to elaborate; maybe
offline.
- 16:42:51 [IanTAG-MI]
- DO: Reason we came up with MIME types and namespaces is to tell us
roughly how to process documents.
- 16:43:51 [IanTAG-MI]
- DC: I'd like to do successive elaboration of arch. In one paragraph,
then in one page, etc.
- 16:44:09 [IanTAG-MI]
- ...I'd like to talk about "clear and present danger" of how to train
working groups.
- 16:44:20 [IanTAG-MI]
- agenda+ how to train WGs
- 16:44:48 [DanC]
- how to traing WGs now, before an arch doc is ready
- 16:45:22 [IanTAG-MI]
- TBL to DO: It is important that people should have an arch document
that gives them the info they need to process content. However, I think
that explaining by saying "this is how you process" is incorrect.
- 16:45:33 [IanTAG-MI]
- ..that's why the arch toc talks about "meaning".
- 16:46:19 [DanC]
- I still like this top-level TOC: 1. Intro to web. 1.a reader view.
1.b provider view. 2. technical arch. 2.a naming b. formats c.
protocols. 3. (maybe) web & society
- 16:46:51 [IanTAG-MI]
- TBL: Heading for section 2 could be "Conveying information."
- 16:47:19 [IanTAG-MI]
- ...the answer is "We convey information by using a set of bits in a
format, and we write specs to define various representations, and we
identify them with URIs."
- 16:47:20 [DanC]
- my proposal for web arch in one page: section "Overview of Web
Architecture" in http://www.w3.org/Architecture/NOTE-ioh-arch
- 16:48:12 [DanC]
- I heard consensus around "Conveying Information".
- 16:49:14 [IanTAG-MI]
- IJ: What does "What is it?" mean?
- 16:49:42 [IanTAG-MI]
- IJ: What are the possible answers to "What is it?"
- 16:49:49 [IanTAG-MI]
- SW: You have an abstraction (a thing).
- 16:49:57 [IanTAG-MI]
- TB: The answer is "That thing is a collection of metadata."
- 16:50:11 [IanTAG-MI]
- NW: Some of the metadata may be useful to you, and some may not.
- 16:50:34 [IanTAG-MI]
- TBL: There is a specification that defines what a spec means. We
identify that language (specification) is using a URI.
- 16:51:21 [IanTAG-MI]
- TB: I think that section 2 is really talking about the metadata about
content. HTTP headers, namespace names: these are in-band metadata.
- 16:51:30 [IanTAG-MI]
- DO: I totally agree with that.
- 16:51:32 [DanC]
- that anti-model of the web is likely worth explaining: neural nets
that eventually converge, as opposed to symbols in web space.
Explaining web architecture by contrast with things that it's not can
be useful.
- 16:52:01 [DanC]
- q+
- 16:52:16 [IanTAG-MI]
- TBL: If I ask you what a document means and you say "A + B + some
other stuff later", then I don't know what the document means.
- 16:52:48 [IanTAG-MI]
- TB: I can't infer meaning by looking at a URI. All I have is the
headers and what's inside the document. What else do I have do deduce
its meaning?
- 16:54:01 [IanTAG-MI]
- DanC: I have trouble with "What does a document mean?" because
context is so important (e.g., you find a check on the floor; cashing
it is fraud). But I don't want to throw up our hands and give up, since
there are many cases when you can get useful information from a
document.
- 16:54:19 [IanTAG-MI]
- DC: Two communication patterns people are familiar with on the Web
are email and http.
- 16:54:50 [IanTAG-MI]
- DC: There is a protocol that people know about - handing each other
documents.
- 16:55:15 [IanTAG-MI]
- TBL: In that sense there is absolute meaning, in that "this is the
meaning this would have if I sent it in email or read it on the
Web."
- 16:55:36 [IanTAG-MI]
- TB: What is the proper name for section 2?
- 16:56:17 [IanTAG-MI]
- TBL: In terms of the "processing model" there is a flow chart - you
receive data, you look at it, instantiate, recursively...
- 16:57:51 [IanTAG-MI]
- Consensus around section 2: "How you convey information"
- 16:58:44 [IanTAG-MI]
- TBL: Mime types appear in XML documents, not just RFC822 headers.
- 16:59:12 [IanTAG-MI]
- DanC: How can you get your hands on a MIME type that doesn't have a
Content-Type next to it?
- 16:59:30 [IanTAG-MI]
- DanC: You could look at it as though the transfer encoding were
already done.
- 17:00:19 [IanTAG-MI]
- DanC: If you get bits + a mime type, the bits might be gzipped. You
can consider the thing after being gunzipped.
- 17:01:02 [IanTAG-MI]
- TBL: Processing model is "First look at the mime type, and
then..."
- 17:01:19 [IanTAG-MI]
- DO: You used the word "processing" TBL....
- 17:01:32 [IanTAG-MI]
- TBL: Anything I can state declaratively, DO, you can create a
processing model for.
- 17:01:48 [TimBL]
- (but not vice versa)
- 17:02:14 [Stuart]
- Stuart has joined #tagmem
- 17:02:35 [IanTAG-MI]
- TBL: Do people agree that we can use the pair MIME type + bits as
"the thing that has absolute meaning (as DanC used)". This defines "a
document".
- 17:03:24 [TimBL]
- How do we convey information?We represent it using strings of bits.
We make up representations - langauges - and write specs which explain
what bits in that language mean, and we identifiy these languages with
URI. The question becomes: What does a (MIME type, bits) pair mean?
- 17:03:34 [IanTAG-MI]
- Resolved: Section two shall be entitled "How to convey
information"
- 17:04:30 [IanTAG-MI]
- DanC: TBL has proposed that MIME type + bits has web-wide meaning,
but I'm only happy with that if in the same sentence, there's something
about http and email.
- 17:04:52 [IanTAG-MI]
- TBL: "What's the meaning of an attachment?" The answer is none.
- 17:05:44 [IanTAG-MI]
- DanC comments on different parts of MIME spec "Multipart-*"
- 17:06:57 [IanTAG-MI]
- ----------
- 17:07:08 [IanTAG-MI]
- Section 3. Representational state transfer
- 17:07:21 [IanTAG-MI]
- TBL: 1. "Snapshot mode" - the approximation of the web ignoring
change
- 17:07:43 [IanTAG-MI]
- TBL: "To support the illusion, for the moment, of an unchanging
Web."
- 17:08:01 [IanTAG-MI]
- TB: Do you imagine this section to be laid out in a way that looks
like RF's dissertation?
- 17:08:04 [IanTAG-MI]
- TBL: I don't know yet.
- 17:09:21 [IanTAG-MI]
- "Rest" protocols are those that maintain the illusion of the
unchanging web (without messages).
- 17:09:34 [IanTAG-MI]
- TB: I find sections 3/4 fuzzier, less meaty than 1/2.
- 17:09:52 [IanTAG-MI]
- TB: I'm not sure we have enough experience to be sure that the
outline for 3/4 is "right" yet.
- 17:10:25 [IanTAG-MI]
- TBL: Perhaps the WS Architecture Group can write their arch document,
and we can leave this fallow for now.
- 17:10:33 [IanTAG-MI]
- SW: Do we want to guide the WS Arch WG?
- 17:10:47 [IanTAG-MI]
- TBL: Can we explain what we'd like to see them do?
- 17:11:57 [IanTAG-MI]
- IJ: Like WAI, I think that TAG should attend early WSArch WG to
convey a path.
- 17:12:31 [IanTAG-MI]
- DanC: Yes. I would hope TAG would visit groups early in their lives.
Help groups understand their obligation to be part of the whole.
- 17:13:19 [IanTAG-MI]
- DO: I hear DanC suggesting a powerpoint document to convey these
points.
- 17:13:28 [IanTAG-MI]
- DanC: Please don't say "Powerpoint". :)
- 17:13:45 [Norm]
- +1 for DanC
- 17:14:52 [IanTAG-MI]
- DO: Yes, I just mean presentation-oriented collateral. That should be
one of our outputs soon.
- 17:15:00 [IanTAG-MI]
- DanC: Real soon, like for the tech plenary.
- 17:15:12 [IanTAG-MI]
- TB: I find it easier to look at the toc in terms of issues that are
being raised.
- 17:15:21 [IanTAG-MI]
- ...for example, our issue 7 fits into section 3 (using GET).
- 17:15:35 [IanTAG-MI]
- ...on the other hand, I don't see any issues coming at us yet that
would fall into section 4.
- 17:15:45 [TimBL]
- q+
- 17:16:11 [IanTAG-MI]
- TB: I support leaving section 4 where it is, and expand when we get
some relevant issues. Or if we don't , take as a lesson that we don't
have much to say in this area.
- 17:16:28 [IanTAG-MI]
- TBL: The Advisory Board also had an all-day meeting yesterday. One
thing that came up:
- 17:16:33 [IanTAG-MI]
- ....how important it is to have roadmaps.
- 17:16:43 [IanTAG-MI]
- ...and could the TAG do this?
- 17:17:09 [IanTAG-MI]
- ..the TAG doesn't establish priorities for how to start activities,
but it can identify dependencies that affect such decisions.
- 17:17:32 [Norm]
- Pls add the URI for the roadmap presentation to the minutes
- 17:18:08 [IanTAG-MI]
- TBL's roadmap:
- 17:18:09 [IanTAG-MI]
- http://www.w3.org/2001/04/roadmap/
- 17:18:26 [TimBL]
- http://www.w3.org/2001/04/roadmap/all.html
etc
- 17:18:29 [IanTAG-MI]
- PC: "What does the W3C do?" is another formulation of the
question.
- 17:18:53 [IanTAG-MI]
- ...I consider that the answer to the question is more of a
communications issue, not an architectural issue.
- 17:19:14 [IanTAG-MI]
- ...I think that the TAG should be doing the arch first, and that then
we focus on communicating this to people.
- 17:20:36 [IanTAG-MI]
- PC: There are many ways to put pieces together (e.g., xml pieces).
Writing an arch document that says "there is one way to put the pieces
together" concerns me.
- 17:21:40 [IanTAG-MI]
- PC: I think we need to identify corner cases and gaps in the
architecture, as we write principles down.
- 17:22:41 [PaulC]
- PaulC has joined #tagmem
- 17:22:42 [IanTAG-MI]
- DO: I think the TAG needs to give some treatment of how pieces relate
in our arch document.
- 17:23:30 [IanTAG-MI]
- TB: I claim that the toc document can do this: If you fill it out,
you will have a current view of the invariants with pointers to specs,
and can be used also to educate working groups and can serve as a
"start here" document.
- 17:24:45 [IanTAG-MI]
- TBL: I think we are confusing some different concepts:
- 17:25:40 [IanTAG-MI]
- 1) One type of roadmap might describe a processing model, another
might illustrate dependencies.
- 17:25:53 [IanTAG-MI]
- ..I think it's the dependencies that are useful to running the
W3C.
- 17:26:42 [IanTAG-MI]
- DO: I could live with having a discussion of dependencies among
specs. That would be a fabulous first step.
- 17:26:58 [IanTAG-MI]
- ..the dynamic processing model is beyond what we need to do right
now.
- 17:27:03 [PaulC]
- I agree with both David and Tim (show dependencies of W3C specs etc)
but I want to work on "to document and build consensus around
principles of Web architecture and to interpret and clarify these
principles when necessary;
- 17:27:14 [IanTAG-MI]
- Paul: Roadmap diagram:
- 17:27:21 [IanTAG-MI]
- http://www.w3.org/2001/04/roadmap/all.html
- 17:27:32 [IanTAG-MI]
- TB: I think that you could naturally fit a discussion of dependencies
into this document.
- 17:27:52 [PaulC]
- Who wants to volunteer to add info on dependencies into our TOC or
underlying document?
- 17:28:05 [IanTAG-MI]
- ...add a section on designing languages. Assert that by default,
languages are in XML. Then you state examples and make it clear where
XML is defined (XML 1.0, namespaces, xml base [And Ian adds XML
accessibility guidelines]).
- 17:28:31 [IanTAG-MI]
- PC: I think that spec dependencies are less important. I would rather
work on principles.
- 17:28:38 [IanTAG-MI]
- DO: I will volunteer to work on dependencies.
- 17:29:15 [DanC]
- DanC has joined #tagmem
- 17:29:57 [DanC]
- under the top section of tag/doc/toc, "What does a URI identify", did
you guys discuss the connection between URIs and noun phrases?
- 17:30:28 [DanC]
- ah... net workie.
- 17:30:55 [IanTAG-MI]
- We talked about renaming section 1 "Naming and identifying
things".
- 17:37:11 [PaulC]
- test.
- 17:37:16 [Norm]
- test.
- 17:38:37 [DanC]
- hmm... vic details... nah, let's pass
- 17:38:40 [IanTAG-MI]
- --------------
- 17:38:53 [IanTAG-MI]
- TBL: I think we've reached the end of the doc toc.
- 17:39:46 [TimBL]
- http://www.w3.org/2001/07/Plenary/Agenda.html
- 17:39:54 [IanTAG-MI]
- On the tech plenary.
- 17:40:04 [IanTAG-MI]
- TBL: We have one hour (at the panel).
- 17:40:08 [TimBL]
- Panelists are TAG members: Dan Connolly, Chris Lilley, David Orchard,
Stuart Williams, Norman Walsh
- 17:40:08 [TimBL]
- Moderator: Paul Cotton
- 17:40:09 [IanTAG-MI]
- PC: Suggested plan:
- 17:40:19 [IanTAG-MI]
- 1) Educate audience about what the TAG actually does.
- 17:40:30 [IanTAG-MI]
- 2) Have some tag participants talk about what we're currently
doing.
- 17:40:42 [IanTAG-MI]
- 3) Gather new issues or input from those present about what we should
be doing.
- 17:41:00 [DanC]
- can we please present web-architecture-on-one-5-slides?
- 17:41:25 [IanTAG-MI]
- Dan, does "on-one-5" mean "101-on-5"?
- 17:41:42 [IanTAG-MI]
- or One-to-Five?
- 17:41:51 [DanC]
- well, it was a typo. 101-on-5 is close enough
- 17:41:59 [IanTAG-MI]
- Thanks.
- 17:42:09 [IanTAG-MI]
- TB: Make sure that the doc toc is featured.
- 17:42:38 [IanTAG-MI]
- PC: Who on the TAG should introduce this document?
- 17:42:40 [DanC]
- I want to be sure we say "Use URIs for important things in your
language, or contact the TAG as to why not. XML Schema is a noted
exception"
- 17:43:15 [IanTAG-MI]
- PC: I'd like to put names next to particular items.
- 17:43:54 [DanC]
- q+
- 17:44:34 [Stuart]
- Stuart has joined #tagmem
- 17:45:00 [IanTAG-MI]
- DanC: When do we present the top 3 (or 5) Web arch principles?
- 17:45:07 [IanTAG-MI]
- ..if not already in outline, please add it.
- 17:45:24 [IanTAG-MI]
- PC: Seems like it overlaps TB's suggestion to point to toc.
- 17:45:34 [IanTAG-MI]
- DanC: Please go into detail on 3-5 points.
- 17:45:54 [IanTAG-MI]
- PC: This would be under part II of the presentation.
- 17:46:14 [IanTAG-MI]
- DanC: I would like to get to the point where, if people don't agree
with some principles, they have to come to us, not the other way
around.
- 17:46:23 [IanTAG-MI]
- Resolved: DanC will present part II.
- 17:46:29 [IanTAG-MI]
- (Sorry, DanC, did you agree to that?)
- 17:46:37 [DanC]
- yup
- 17:46:39 [IanTAG-MI]
- Resolved: NW will present part I.
- 17:46:58 [IanTAG-MI]
- Resolved: PC will moderate, and run part III.
- 17:47:17 [IanTAG-MI]
- Scheduling: 5 mins for introduction, 10 mins for part I,
- 17:47:51 [IanTAG-MI]
- 20 mins for part II, 10 mins for questions on Part II, 20 mins for
part III.
- 17:48:15 [DanC]
- are there strategic meals?
- 17:48:19 [IanTAG-MI]
- PC: It might be appropriate to have a TAG BOF table at lunch on
weds.
- 17:48:23 [DanC]
- great minds think alike ;-)
- 17:48:29 [IanTAG-MI]
- And eat alike. :)
- 17:48:52 [IanTAG-MI]
- NW: Do you want two tag teams on weds?
- 17:49:01 [IanTAG-MI]
- PC: BOFs are normally concentrated on weds.
- 17:49:23 [IanTAG-MI]
- (Two tag tables on Weds.)
- 17:49:35 [IanTAG-MI]
- DO: Please discuss how we would like people to approach us in
general.
- 17:50:14 [IanTAG-MI]
- Check out "tips for getting TAg's attention" http://www.w3.org/2001/tag/#mail
- 17:50:37 [IanTAG-MI]
- If you come up with other ones, please let me know and I'll add them
to that section.
- 17:51:02 [DanC]
- q+
- 17:51:15 [DanC]
- I agree: i fyou want the TAG's attention, summarize the history.
- 17:51:39 [IanTAG-MI]
- TBL: People may ask us to look broadly at documents because they
"feel" that the document is bad architecturally. They may not want to
explain or be able to explain why it's bad.
- 17:51:45 [DanC]
- meanwhile, the "if you have a problem with XYZ, talk to the XYZ WG
first" idea... we didn't exactly lead by example there. Tim Bray's
XML-SW hardly went to the XML Core WG first.
- 17:52:48 [IanTAG-MI]
- PC: DO sent email to chairs list. Have people looked at replies to
query?
- 17:54:20 [IanTAG-MI]
- Responses:
- 17:54:31 [IanTAG-MI]
- - Where TAG fits in
- 17:54:42 [IanTAG-MI]
- (For NW)
- 17:54:54 [IanTAG-MI]
- ....add "QA" to the list in Charles' email.
- 17:55:11 [IanTAG-MI]
- - List of architectural divergences
- 17:55:14 [IanTAG-MI]
- http://lists.w3.org/Archives/Public/www-tag/2002Feb/0080.html.
Note. These comments originally sent to chairs list;
forwarded to www-tag after this meeting.
- 17:55:30 [IanTAG-MI]
- ">
- 17:55:30 [IanTAG-MI]
- >I'd like the TAG to make a list of architectural divergences
(or
- 17:55:30 [IanTAG-MI]
- >perceived as such) between W3C specs (e.g. xpath syntax different
from
- 17:55:30 [IanTAG-MI]
- >css selector syntax, Device Independence vs. WAI guidelines,
xlink vs
- 17:55:30 [IanTAG-MI]
- >XHTML object vs SMIL switch for doing media inclusion, etc), and
for
- 17:55:31 [IanTAG-MI]
- >each one, provide a rationale and a plan for potential
convergence.
- 17:55:33 [IanTAG-MI]
- "
- 17:55:37 [DanC]
- I see QA in this thread... I'll be glad to know how QA wants to
interact with WGs.
- 17:56:04 [IanTAG-MI]
- PC: I'm not sure what our relationship to QAWG would be.
- 17:56:21 [IanTAG-MI]
- - From RDF Core WG: http://lists.w3.org/Archives/Public/www-tag/2002Feb/0084.html.
Note. These comments originally sent to chairs
list by Brian McBride, were forwarded to www-tag after this meeting.
- 17:56:36 [IanTAG-MI]
- "RDFCore would like the TAG to clarify and define the foundations of
the
- 17:56:36 [IanTAG-MI]
- architecture of the web. The concept of a resource is fundamental to
web
- 17:56:36 [IanTAG-MI]
- architecture, yet it is very hard to pin down exactly what it means
and how
- 17:56:36 [IanTAG-MI]
- it relates to the concepts of URI, URI reference and XML
namespace.
- 17:58:08 [IanTAG-MI]
- PC: I don't know what we will do about divergences. We might ask the
audience for their view on this.
- 17:59:21 [IanTAG-MI]
- DanC: There isn't any arch principle why xlink and xhtml object have
to be the same. It's inconvenient that they're different.
- 17:59:29 [IanTAG-MI]
- PC: Is this an issue that the TAG wants to take up?
- 17:59:40 [IanTAG-MI]
- IJ: I note that this has not reached our agenda since not sent to
www-tag.
- 18:01:58 [TimBL]
- We will break 13:30-14:00
- 18:02:04 [IanTAG-MI]
- ----------------------------------------
- 18:02:06 [TimBL]
- ------------------------------------------------------------------
- 18:02:38 [IanTAG-MI]
- TBL: Let's prioritize / separate issues (if we can).
- 18:03:13 [PaulC]
- Is this URL valid http://www.w3.org/2002/02/12-tag-threads.html?
- 18:04:33 [DanC]
- IanTAG-MI, the "see tips for getting..." link from http://www.w3.org/2001/tag/#mail
doesn't go anywhere.
- 18:05:02 [TimBL]
- http://www.w3.org/2001/tag/ilist
<- Issues list
- 18:05:57 [IanTAG-MI]
- Arch threads will be available later at http://www.w3.org/2002/02/04-tag#threads
- 18:06:12 [IanTAG-MI]
- ------------------------------
- 18:06:16 [IanTAG-MI]
- namespaceDocument-8: What should a "namespace document" look
like?
- 18:06:32 [IanTAG-MI]
- http://www.w3.org/2001/tag/ilist#namespaceDocument-8
- 18:06:52 [IanTAG-MI]
- TBL: The info you put in a namespace document should be the most
useful info you can given the language you are using and the state of
the art.
- 18:07:03 [IanTAG-MI]
- DanC, so far I have not put upcoming meetings in news.
- 18:07:20 [IanTAG-MI]
- TB: My thoughts are on record. The crucial thing about RDDL is that
it's human-readable.
- 18:07:49 [IanTAG-MI]
- ...the population of namespaces falls into two categories - those I
know what to do with and those I don't.
- 18:08:08 [IanTAG-MI]
- TB: Whatever serves as the namespace document ought to have a
human-readable resource.
- 18:08:26 [IanTAG-MI]
- ..people need to be able to read a human-readable expression to allow
developers to move forward.
- 18:08:46 [IanTAG-MI]
- TBL: I feel the reverse - fundamentally it's important to be readable
by machines. So much the better if can be read by humans.
- 18:09:19 [IanTAG-MI]
- TBL: If you have something that has some human-readable info and some
machine-readable, there is a security gap and an architectural
hole.
- 18:09:32 [IanTAG-MI]
- ...you really ought to say "The definitive meaning is in the
RDDL."
- 18:09:55 [IanTAG-MI]
- ..to have two different meanings is a security hole.
- 18:10:13 [IanTAG-MI]
- DO: One of the key questions is: who is the target audience of the
namespace name? Human? Software?
- 18:10:23 [IanTAG-MI]
- DanC: Do you expect the same answer in all cases?
- 18:10:41 [IanTAG-MI]
- DanC: To me a namespace is not interestingly distinguishable from a
Web resource.
- 18:10:56 [DanC]
- I would consider it progress if we could get to the point of saying:
either RDDL or XML Schema is acceptable, architecturally. (after all,
you can convert RDDL to RDF for machines, and you can style XML Schemas
with XSLT for humans)
- 18:11:02 [IanTAG-MI]
- TBL: We can't and shouldn't limit the architecture to aim for a
particular audience.
- 18:11:48 [DanC]
- ... progress... agreed: there are practical issues, and maybe we
could reommend some practices. but either RDDL or XML Schema is so much
better than 404.
- 18:11:52 [DanC]
- q+
- 18:12:13 [TimBL]
- .
- 18:12:50 [IanTAG-MI]
- IJ: Sounds like we are saying: (1) we do the best we can to
communicate author meaning to others (2) we can't guarantee that it
will be understood by machines or people (3) recipient may extract
other meaning than what author intended.
- 18:13:13 [IanTAG-MI]
- TB to DanC: I think that namespace names, when they are actually
used, will in most cases be used for recognition.
- 18:13:56 [IanTAG-MI]
- TB: In the case where namespace names are used by software, they are
typically not dereferenced.
- 18:14:32 [IanTAG-MI]
- DanC?
- 18:14:50 [IanTAG-MI]
- DC: It would be progress if we got to the point of saying either RDDL
or XML Schema is better than 404.
- 18:15:00 [IanTAG-MI]
- (or even plain text).
- 18:15:08 [IanTAG-MI]
- DC: Then we can talk about pitfalls and advantages of either one.
- 18:15:24 [IanTAG-MI]
- DC: Who has the action item to go tell the world?
- 18:15:41 [IanTAG-MI]
- IJ: Paul does.
- 18:16:13 [PaulC]
- test
- 18:16:15 [IanTAG-MI]
- TBL: We should emphasize that this applies to namespaces.
- 18:16:49 [DanC]
- yes, please specially note that this applies to namespaces
- 18:17:20 [IanTAG-MI]
- Resolved: The point about URIs should have dereferencable material at
their end applies to namespaces.
- 18:17:42 [IanTAG-MI]
- There is disagreement over TB's assertion that software will not
likely dereference URIs used as namespace names.
- 18:18:00 [IanTAG-MI]
- (Namely disagreement by DC and TBL).
- 18:18:21 [DanC]
- q+
- 18:18:30 [DanC]
- Zakim? hello?
- 18:18:44 [IanTAG-MI]
- Zakim responded....
- 18:19:25 [IanTAG-MI]
- TB summarizing TBL: You are writing a recursive validator to bring
multiple schemas into play, and doing so involves dereferencing
namespace URIs?
- 18:19:27 [IanTAG-MI]
- TBL: Yes.
- 18:19:39 [IanTAG-MI]
- TBL: I'm not using XML Schemas, I'm using RDF schemas.
- 18:19:44 [IanTAG-MI]
- zakim, who's on the queue?
- 18:19:45 [Zakim]
- I see DanC on the speaker queue
- 18:20:21 [DanC]
- are they in the same room?
- 18:20:34 [IanTAG-MI]
- TBL: Just as a clarification: there is a complicated algorithm - you
either find a schema or something that tells you how to resolve
....@@
- 18:20:45 [Norm]
- q?
- 18:21:13 [DanC]
- that bit from the namespace spec is a bug. let's please fix it.
- 18:21:17 [DanC]
- "it is not a goal...".
- 18:21:32 [IanTAG-MI]
- TB: It is not a design goal that these things be used to get a
scheme. I would stand by the statement that the overwhelming majority
of software will not dereference these URIs.
- 18:21:53 [DanC]
- i was in the WG that ratified that document, and I specifically
understood "it is not a goal..." to mean "it's not a goal fo this spec,
but it may well be a goal of higher level specs; esp schema specs"
- 18:21:57 [IanTAG-MI]
- TBL: TB is speaking on behalf of a lot of XML applications. But I'm
speaking about another class of applications where my sanity depends on
being able to derference these URIs.
- 18:22:10 [Norm]
- norm acks dan
- 18:22:15 [Norm]
- zakim, ack dan
- 18:22:16 [Zakim]
- I see no one on the speaker queue
- 18:22:42 [IanTAG-MI]
- DC: RDF Schema layered on top is not broken.
- 18:22:50 [PaulC]
- q?
- 18:23:00 [PaulC]
- david orchard on queue
- 18:23:11 [TimBL]
- q=do
- 18:23:24 [IanTAG-MI]
- PC: People started to talk about namespaces, then switched to talking
about finding schemes.
- 18:23:40 [IanTAG-MI]
- ....XQuery has a couple of namespaces for which there are no
schemas.
- 18:24:12 [IanTAG-MI]
- DC: You have something in mind for the use of the terms in a
namespace, I can write a document that describes them, that document is
a schema.
- 18:24:19 [IanTAG-MI]
- ...and I can write a machine-readable version.
- 18:25:14 [IanTAG-MI]
- PC: The only thing that exists on the W3C site today is an xhtml
file, no list of functions, etc.
- 18:25:22 [IanTAG-MI]
- TBL: No signature file, no axioms, ....
- 18:25:56 [IanTAG-MI]
- DanC: A machine can determine that w3c takes responsibility for this
identifier. A machine can follow links within the xhtml document.
- 18:26:05 [IanTAG-MI]
- PC: If you look at the xhtml file, it points to a WD.
- 18:26:29 [IanTAG-MI]
- ...if you did a search for the text in the WD, it would tell you that
everything in the WD prefixed by xf: are things in that namespace.
- 18:26:37 [Norm]
- q+ timbray
- 18:26:53 [IanTAG-MI]
- DanC: I don't mean that a machine has to be able to get this
information (but it can).
- 18:27:03 [Norm]
- zakim ack do
- 18:27:08 [Norm]
- ack do
- 18:27:13 [DanC]
- by "schema" I mean: a document that explains the usage of a
vocabulary of terms.
- 18:27:19 [IanTAG-MI]
- DO: I'm confused by our terms. When I hear "schema", I think of a
language like xml schema or dtd's or rdf schema, etc.
- 18:27:29 [Norm]
- q+ timbl
- 18:27:32 [IanTAG-MI]
- DO: I hear DanC saying an xhtml document can be a schema too.
- 18:27:36 [IanTAG-MI]
- DanC: Yes, that's true.
- 18:27:53 [IanTAG-MI]
- TBL: I propose that we say that a schema is a document that describes
some aspect of a language.
- 18:28:04 [IanTAG-MI]
- DO: I object.
- 18:28:09 [Norm]
- ack timbray
- 18:28:11 [IanTAG-MI]
- PC: A better name is "namespace document"
- 18:28:22 [TimBL]
- TB: But that is beggingthe question
- 18:28:31 [DanC]
- I'm happy to introduce new terms: bannana/pear/apple or whatever.
- 18:28:35 [DanC]
- Q+
- 18:28:38 [DanC]
- re indirection.
- 18:28:39 [IanTAG-MI]
- TB: I advanced the principle that a namespace document should be
human-readable. I also think a namespace document should provide one
level of indirection.
- 18:28:48 [DanC]
- XML Schema has just as much indirection as RDDL
- 18:28:58 [IanTAG-MI]
- TB: In the world of server-side software, schemas aren't that
important. We don't use them at runtime.
- 18:29:11 [IanTAG-MI]
- ...we use other things at runtime like style sheets and xslt
resources and java classes.
- 18:29:18 [TimBL]
- so why does an indirection help?
- 18:29:19 [Norm]
- q+
- 18:29:30 [Norm]
- ack timbl
- 18:29:54 [IanTAG-MI]
- TBL: When there is only a schema, why do you need an indirection?
- 18:30:14 [IanTAG-MI]
- TBL: RDDL and RDF Schema and anything else written in RDF are
sufficiently powerful languages to be able to include indirections to
anything else.
- 18:30:54 [IanTAG-MI]
- TBL: Indirection is an important tool. But to prevent someone from
writing namespace information directly in the namespace document is a
shame.
- 18:31:29 [IanTAG-MI]
- TBL: The architecture should give you the tools to do the sorts of
things we envisage that you will want to do.
- 18:31:44 [IanTAG-MI]
- ...we know that you will want to include a variety of information,
and to be able to include references to other information.
- 18:31:52 [IanTAG-MI]
- ...so far the tools that we have allow you to do that.
- 18:31:54 [PaulC]
- q+ DavidO
- 18:32:05 [Norm]
- ty PaulC
- 18:32:11 [Norm]
- q+ timbray
- 18:32:12 [PaulC]
- q+ Timb
- 18:32:16 [Norm]
- ack dan
- 18:32:18 [Norm]
- ack danc
- 18:32:46 [IanTAG-MI]
- DanC: How is a schema doc that points to a rddl document less cool
than a rddl document that points to a schema document? Seems like it's
all the same. You can do whatever is most convenient at the time.
- 18:33:06 [IanTAG-MI]
- DanC: I'd like TB to explain why RDDL is special w.r.t. other formats
one might find?
- 18:33:21 [IanTAG-MI]
- DanC: Why is xml schema not appropriate as the first thing you
find?
- 18:33:36 [IanTAG-MI]
- DanC: XML Schemas are human-readable.
- 18:34:09 [IanTAG-MI]
- TB: XML Schemas not primarily designed to be human readable.
- 18:34:22 [IanTAG-MI]
- DanC: I thought you said "architecturally broken to put XML Schema
there"
- 18:34:46 [IanTAG-MI]
- TB: Yes, I think it's architecturally broken to put an XML Schema in
a ns document.
- 18:35:23 [IanTAG-MI]
- DanC: The claim is not that XML schemas provide everything you need
(since you can point to other useful resources).
- 18:35:46 [IanTAG-MI]
- DanC: All of these formats have indirections.
- 18:36:01 [IanTAG-MI]
- DanC: I can't see the architectural difference between RDDL, Schemas,
etc.
- 18:36:20 [TimBL]
- q?
- 18:36:25 [PaulC]
- q- Timb
- 18:36:54 [Norm]
- ack norm
- 18:37:03 [IanTAG-MI]
- NW: There is clearly "no right answer": You put the thing at end of
the URI that will be most useful to the community that will be looking
there.
- 18:37:10 [Norm]
- ack davido
- 18:37:18 [IanTAG-MI]
- DC: TB asserts that there are some things that should not be put at
the end of the URI.
- 18:37:33 [DanC]
- I'd be happy to agree "there's no right answer"; but I hear Bray
arguing there are wrong answers.
- 18:37:47 [Norm]
- q+
- 18:38:02 [DanC]
- I can support DO's pragmatic argument: HTML browsing is more widely
deployed.
- 18:38:09 [IanTAG-MI]
- DO: I think that human readable schemas should be first since people
have browsers. This is pragmatics. People have browsers, but not schema
viewers.
- 18:38:09 [TimBL]
- q+
- 18:38:26 [PaulC]
- The Namespace http://www.w3.org/1999/xhtml
gives us an HTML document.
- 18:38:31 [IanTAG-MI]
- DO: We've not thought about multiple versions of our schema
languages.
- 18:38:37 [DanC]
- speak for your self, DaveO. I've thought a lot about versions of
schema languages.
- 18:39:04 [IanTAG-MI]
- DO: You need a layer of indirection to deal with evolution of the
schema language itself.
- 18:39:12 [DanC]
- I have runnin code that handles evolution of schema languages: http://www.w3.org/2001/05ve/
- 18:39:14 [IanTAG-MI]
- q?
- 18:39:18 [TimBL]
- 1) Humans reading is most inportant b) we only have tools to
automatically process schema
- 18:39:23 [TimBL]
- ack N
- 18:39:48 [IanTAG-MI]
- NW: Do you agree that architecturally (pragmatics aside), things with
pointers or schemas are the same thing?
- 18:39:51 [IanTAG-MI]
- TB: I don't buy it.
- 18:40:03 [IanTAG-MI]
- ...I don't want to have to download additional descriptions.
- 18:40:13 [DanC]
- but isn't that a practical objection? the chair asked "practical
issues aside..."
- 18:40:19 [IanTAG-MI]
- TB: ....I can provide higher quality tutorial material about vocabs
I'm trying to describe.
- 18:40:24 [TimBL]
- HA!
- 18:40:25 [TimBL]
- :)
- 18:41:09 [Norm]
- q?
- 18:41:49 [Norm]
- ack timbl
- 18:42:03 [Norm]
- you look confused paul, have I overlooked yo?
- 18:42:05 [Norm]
- you?
- 18:42:41 [PaulC]
- http://www.w3.org/2001/05ve/
appears to be a directory of software? Is there a human readable
description of your thoughts on this?
- 18:42:41 [IanTAG-MI]
- TBL: DO says that the most important thing is to present things to
people (since that's what we've got for the moment). Bu we have lots of
things that slurp up schemas (most of them are automated tools).
- 18:43:02 [IanTAG-MI]
- TBL: We have people using schemas, even if people are not presenting
them as such.
- 18:43:12 [DanC]
- 05ve: no, I haven't really written it up, unfortunately, I don't
think. (lemme google for backlinks to be sure...)
- 18:43:55 [IanTAG-MI]
- A list of schema processors available at http://www.w3.org/XML/Schema
- 18:44:57 [IanTAG-MI]
- TBL: There are use cases for having something machine-processable at
the end of a namespace URI.
- 18:45:13 [IanTAG-MI]
- TB: I am for something useful that's machine-processable, but I think
it should be after a redirection.
- 18:45:36 [IanTAG-MI]
- DanC: But XML Schema *has* one level of indirection.
- 18:45:55 [IanTAG-MI]
- DanC: I can see pragmatic arguments, but not architectural
principles.
- 18:46:08 [IanTAG-MI]
- TBL: You can write an XML schema document that has xhtml and rddl and
not much xml schema.
- 18:46:20 [IanTAG-MI]
- TB: Are there any arch principles on which we can agree here?
- 18:46:31 [IanTAG-MI]
- - A) Should be human readable first
- 18:46:44 [IanTAG-MI]
- - B) Should have indirection to get to other useful things.
- 18:46:54 [IanTAG-MI]
- DanC: I agree on pragmatic issues.
- 18:47:06 [IanTAG-MI]
- TB: XML Schema is a heavyweight way to encode the indirection.
- 18:47:50 [IanTAG-MI]
- NW: This seems to have devolved into pragmatic issues. Should we be
making purely arch principle decisions based on pragmatics?
- 18:48:04 [PaulC]
- q+
- 18:48:12 [IanTAG-MI]
- DanC: Arch principles are the invariants. Deployment of software
shouldn't change them.
- 18:48:42 [DanC]
- Norm, Bray proposed two things (a) human-readable, (b) indirection.
We're talking about indirection. When we get to human-readable, I'
- 18:48:47 [DanC]
- ... I'd like the floor
- 18:48:48 [DanC]
- q+
- 18:48:55 [Norm]
- ok
- 18:49:03 [IanTAG-MI]
- TBL: Do we need to establish any arch principles here?
- 18:49:11 [PaulC]
- Q: are Timbl and Dan saying that any kind of document can be used at
the end of a Namespace?
- 18:49:15 [IanTAG-MI]
- TBL: ..is there a hole we'll fall into by putting the xml schema
there?
- 18:49:33 [DanC]
- q= DanC
- 18:49:37 [Norm]
- ty DanC
- 18:50:01 [TimBL]
- ty?
- 18:50:13 [Norm]
- Thank you for clearing the queue (i forgot how)
- 18:50:21 [Norm]
- ty=thank you,timbl
- 18:50:32 [TimBL]
- ta
- 18:50:47 [IanTAG-MI]
- PC: Are you saying that the arch principle is to allow the Web to
permit any kind of document at all at the end of a namespace URI?
- 18:51:06 [TimBL]
- xhtml10-namespace.svg
- 18:51:31 [IanTAG-MI]
- TBL: I didn't say "I don't care what's there" I just said that no
arch princple is broken by putting something that's not useful at the
end of the URI.
- 18:51:46 [IanTAG-MI]
- TBL: There are lots of different ways to help people. And to be
impractical.
- 18:52:06 [IanTAG-MI]
- TBL: I (personally) want to be able to turn whatever is that the end
of the URI into RDF.
- 18:52:18 [DanC]
- agreed: please read "I don't care what sort of document you put
there" as "there's no way you can break architectural principles by
choosing among data formats to use to document your namespace"
- 18:52:20 [Norm]
- q+ timbray
- 18:52:51 [IanTAG-MI]
- NW Summarizing:
- 18:52:57 [IanTAG-MI]
- a) We are saying that something should be there.
- 18:53:02 [IanTAG-MI]
- b) We have no consensus on what should be there.
- 18:53:05 [PaulC]
- When are we breaking for Lunch or Brunch?
- 18:53:06 [Norm]
- ack danc
- 18:53:07 [DanC]
- http://www.w3.org/DesignIssues/Formats.html
- 18:53:19 [TimBL]
- Break for lunch them moment we can
- 18:53:36 [IanTAG-MI]
- "A server providing a format which is not in the basic set of formats
required for a client must have the possibility of generating some sort
of conversion of the text (even if necessary an apology for
non-conversion in the case of graphics to text) for a client which
cannot handle it. This ensures universal readability world over.
- 18:53:36 [IanTAG-MI]
- "
- 18:54:01 [IanTAG-MI]
- DanC: Can HTML be replaced or, as TBL once said, is it special?
- 18:54:55 [PaulC]
- q+ DavidO (before lunch)
- 18:55:04 [Norm]
- ok
- 18:55:14 [IanTAG-MI]
- TBL: What I expect to respond (after lunch) is that it's a best
practice to be able to convert to HTML. And for the case of someone on
a plane, it's important to be able to convert to plain text. But for
machine-readable, it's a different fork.
- 18:55:35 [Norm]
- ack timbray
- 18:55:40 [Norm]
- ack before, lunch
- 18:55:47 [Norm]
- q=davido
- 18:56:27 [DanC]
- ah... interesting point...
- 18:56:28 [IanTAG-MI]
- TB: I am happy for TBL to produce RDF, and to be able to point to it
from a namespace document. I think that the key way to convey the
meaning of a language is in human-readable prose.
- 18:56:33 [Norm]
- ack davido
- 18:56:47 [TimBL]
- Hmena langauges are boostrapped from human readable langauges, MR
from MR
- 18:57:05 [TimBL]
- Human readable langauges are boostrapped from human readable
langauges, MR from MR
- 18:57:54 [IanTAG-MI]
- DO recasts the issue in terms of the content type of the thing at the
end of the URI.
- 18:58:16 [TimBL]
- BUT I can convert MR to HR not the other way around.
- 18:58:27 [IanTAG-MI]
- ------------------
- 18:58:28 [IanTAG-MI]
- LUNCH
- 18:58:29 [IanTAG-MI]
- ----------------------
- 18:58:51 [Zakim]
- -DanC
- 19:22:24 [DanC]
- DanC has joined #tagmem
- 19:23:31 [TimBL]
- TimBL has joined #tagmem
- 19:42:09 [TimBL]
- TimBL has joined #tagmem
- 19:42:14 [TimBL]
- http://www.daml.org/ontologies/uri.html
- 19:42:47 [TimBL]
- <- list of some nmespaces which have DAML ontologies
- 19:46:42 [TimBL]
- DanC we are restarting ......................................
- 19:47:01 [TimBL]
- DanC had asked...
- 19:47:24 [IanTAG-MI]
- TBL: DanC asked me if I still thought people should be able to reduce
information to plain text.
- 19:47:35 [IanTAG-MI]
- TBL: Yes, at least for accessibility.
- 19:47:49 [TimBL]
- ... by people with terminals.
- 19:48:46 [IanTAG-MI]
- TBL: There are richer and less rich formats. Machine readable formats
are richer than human readable formats (in a sense) since you can't go
back to the precision of the machine-readable format.
- 19:49:19 [IanTAG-MI]
- TBL: It is reasonable to say that it's a good idea to be able to
revert something to plain text.
- 19:49:52 [IanTAG-MI]
- IJ: Timed text is not captured in plain text.
- 19:50:00 [IanTAG-MI]
- TB: HTML is the ASCII of today.
- 19:50:04 [IanTAG-MI]
- TB Summarizing:
- 19:50:33 [IanTAG-MI]
- - It's not desirable to put "nothing" at the end of a namespace
URI.
- 19:50:44 [IanTAG-MI]
- - We don't have consensus on what should be there.
- 19:50:54 [IanTAG-MI]
- q+
- 19:51:40 [IanTAG-MI]
- TB: I'm afraid that if we say that you can put anything at the end of
the URI, you might see large monolithic schemas (without indirections,
in practice).
- 19:52:08 [IanTAG-MI]
- TBL: Does everyone know what I mean when I refer to "XML Schema
annotations for RDF?"
- 19:52:13 [IanTAG-MI]
- (Chorus of no's)
- 19:52:54 [IanTAG-MI]
- TBL: XML Community resists writing well-structured data in RDF.
- 19:53:46 [IanTAG-MI]
- Henry Thompson has shown that with little extra information, XML
documents can be interpreted using RDF model.
- 19:54:05 [IanTAG-MI]
- ...you can give XML Schema designers a vocabulary for translating xml
schema instances into RDF.
- 19:54:24 [IanTAG-MI]
- ...this will benefit RDF world, and will promote consistency with RDF
world.
- 19:54:32 [IanTAG-MI]
- TB: Will people go to extra effort to annotate XML schemas?
- 19:54:38 [IanTAG-MI]
- TBL: I don't think so. But RDF people can.
- 19:54:49 [IanTAG-MI]
- ....we need a set of use cases. WSDL is an interesting use case.
- 19:55:44 [IanTAG-MI]
- TBL: Should the TAG promote schema annotations?
- 19:55:54 [IanTAG-MI]
- PC: Is this the thread discussed on the floor of the previous AC
meeting?
- 19:56:20 [IanTAG-MI]
- TBL: It wasn't discussed in detail, but people said "yes, yes, yes".
It also came up in Web SErvices workshop, where people also said "yes,
why don't we do that."
- 19:56:42 [IanTAG-MI]
- TBL: I think that this will also relieve tension between XML and RDF
communities.
- 19:57:03 [IanTAG-MI]
- PC: Don't know what the role the TAG has here. Or maybe we think this
is a missing piece, and we want some WG to tackle this.
- 19:57:24 [IanTAG-MI]
- PC: The mantra is: don't mark up the instances, mark up the
schemas.
- 19:58:40 [IanTAG-MI]
- TB: I don't feel I have enough background to say whether this is a
missing piece of the architecture.
- 19:58:45 [IanTAG-MI]
- TBL Proposed:
- 19:59:12 [IanTAG-MI]
- - A good thing: A method of putting info in an XML Schema document
that explains how to extract RDF from instances of the schema.
- 19:59:41 [IanTAG-MI]
- - This should be promoted as a way that would allow people to avoid
the XML syntax of RDF and just write XML Schemas.
- 20:01:19 [IanTAG-MI]
- TB: I think that it's an excellent idea to pull out RDF statements
from schema statements. But doing anything to schemas may take a long
time.
- 20:01:29 [IanTAG-MI]
- PC: But the extensibility mechanism is already there in XML
Schema.
- 20:02:34 [IanTAG-MI]
- TB: Then yes, I think this is a good idea. But I still have the worry
that people writing schemas will have no incentive to add the
annotations. This suggests to me more strongly that indirection is
required in namespace documents.
- 20:03:06 [IanTAG-MI]
- PC: I am a big supporter of this work. I think that my company should
commit resources to bridging the gap between XML Schemas and the RDF
community.
- 20:03:35 [IanTAG-MI]
- PC: But what's the TAG's role?
- 20:04:07 [IanTAG-MI]
- PC: Why is this not in proposed reorg of XML activity?
- 20:04:15 [IanTAG-MI]
- ...should TAG comment on the activity proposal?
- 20:04:30 [IanTAG-MI]
- TBL: The Team sometimes gets cold feet to do things it has not been
given the mandate to do.
- 20:04:49 [IanTAG-MI]
- PC: Huh? There are plenty of instances of the Team doing that.
- 20:06:12 [IanTAG-MI]
- TBL: AC reps can raise issues w3c-ac-forum.
- 20:06:30 [PaulC]
- Text from the XML Schema WG charter: "to cooperate with other W3C
working groups and assist them in exploiting XML Schema for their work
and adding schema-awareness to their specifications where
appropriate
- 20:08:04 [IanTAG-MI]
- DO: People don't bring up technical issues in ac-forum.
- 20:08:16 [IanTAG-MI]
- ...seems like the TAG is a more natural venue for this type of
issue.
- 20:10:20 [IanTAG-MI]
- PC: I think that this should go to the XML CG and Chair of RDF core
and suggest that they create a task force to talk about this.
- 20:10:42 [IanTAG-MI]
- TB: Sounds like desire is more on the RDF side. Lots of XML people
don't care about RDF in the slightest.
- 20:10:50 [IanTAG-MI]
- TBL: You can't ask one side to do this unilaterally.
- 20:11:07 [IanTAG-MI]
- TBL: That's why this issue has fallen between the cracks.
- 20:11:29 [IanTAG-MI]
- PC: Refer to cambridge communique http://www.w3.org/TR/1999/NOTE-schema-arch-19991007
- 20:12:16 [IanTAG-MI]
- PC: You wlil only solve this problem by finding people to do the
work.
- 20:12:17 [TimBL]
- provide an account of the relationship between RDF and the XML family
of technologies (particularly Schemas and Infoset/Query)
- 20:12:26 [TimBL]
- - from http://www.w3.org/2001/sw/RDFCoreWGCharter
- 20:14:21 [IanTAG-MI]
- IJ: I suggest looking at the assertion "XML Schema should not be
there (TB)"
- 20:14:47 [IanTAG-MI]
- IJ: Rather than trying to get consensus about what (if anything)
should be there.
- 20:15:15 [IanTAG-MI]
- DO: I think that the Semantic Web people would prefer to have an html
document than a schema document...
- 20:15:34 [IanTAG-MI]
- TBL: From Sem Web point of view, html document doesn't work since
human readable.
- 20:16:05 [IanTAG-MI]
- TB: It would be a valuable thing to have a required thing in RDDL
saying "This is RDDL 2."
- 20:18:26 [IanTAG-MI]
- TBL: A MIME type of "text/*" is that something is essentially
human-readable. But because such a document is essentially for humans,
then not processable readibly by machines (e.g., due to security holes
when human-readable text and machine instructions contradict each
other).
- 20:19:00 [IanTAG-MI]
- TB: The concern TBL is expressing is that there's no way to guarantee
consistency between human readable and machine readable text.
- 20:19:22 [IanTAG-MI]
- DO: If everyone put a schema document there, and put an html
annotation inside, how is this different?
- 20:19:45 [IanTAG-MI]
- TBL: In my model, it depends on what the outermost document is. If
outermost document is an HTML document, then everything else should be
taken as "FYI only".
- 20:20:01 [IanTAG-MI]
- ...however, if the outermost piece is a schema document, that's
different.
- 20:20:33 [IanTAG-MI]
- ...fundamentally, it's not an html document. Even if someone has a
schema reader.
- 20:21:15 [IanTAG-MI]
- TBL: You can style html annotations because schema processor can hand
off app-info bits.
- 20:21:29 [IanTAG-MI]
- DO: So you think that because something is inside an appinfo element,
then that declares it to be true.
- 20:21:45 [IanTAG-MI]
- TBL: That is the intent: you can put info in another format in the
appinfo element.
- 20:22:22 [IanTAG-MI]
- DO: Where we disagree - in many cases, I think that appinfo will be
out of date since just comments.
- 20:23:08 [IanTAG-MI]
- DO: I'm not sure that xml schema with embedded appinfo is more
certain than xhtml with embedded info.
- 20:23:42 [IanTAG-MI]
- TBL: The key is that the outer format needs to say how you can use
embedded information. HTML has not said how you can process embedded
information.
- 20:23:51 [IanTAG-MI]
- q+ TB
- 20:24:40 [IanTAG-MI]
- NW: Why would I believe that embedded HTMl is any more true about a
schema?
- 20:25:03 [IanTAG-MI]
- TB: Imagine a RDDL document that contains a description about what a
namespace is about. And it contains pointers to schemas and dtds and
other useful things.
- 20:25:19 [IanTAG-MI]
- ...the pointers aren't human-readable (hidden in xlinks).
- 20:25:36 [IanTAG-MI]
- ...there is a concern that there could be a pointer to an active X
component that melts your hard drive.
- 20:26:08 [IanTAG-MI]
- ...suppose you wrote into RDDL a requirement that the first
non-header element contain text that says "This document contains
pointers and should be trusted". Would this allay some of your
concenrs.
- 20:26:19 [IanTAG-MI]
- TBL: Formally yes, but it's hairy.
- 20:26:49 [IanTAG-MI]
- TBL: It's only in English. And since I want to automate processes, I
will have to search for the English string.
- 20:26:50 [PaulC]
- q+ DavidO
- 20:26:59 [IanTAG-MI]
- q- IanTAG-MI
- 20:27:14 [IanTAG-MI]
- TBL: The person and the machine must follow the same route.
- 20:27:21 [IanTAG-MI]
- q- TB
- 20:27:26 [TimBL]
- ack d
- 20:28:41 [IanTAG-MI]
- TBL: If I ask you to define the function "What does a document mean?"
do you want to say that "if in the first 200 bytes it has to include
some English phrase, then you should process as follows."?
- 20:28:50 [IanTAG-MI]
- TBL: I'd prefer to use content negotiation.
- 20:29:05 [IanTAG-MI]
- SW: I'd prefer to use content negotiation.
- 20:29:25 [IanTAG-MI]
- TB: Content negotiation is not a solution. HTML has three different
DTDs. It doesn't solve this problem.
- 20:29:54 [IanTAG-MI]
- TBL: I agree that what you get back has to point to a bunch of
different things. But it does allow you to choose something that is for
humans v. something that is for machines.
- 20:30:09 [PaulC]
- I have already suggested we move on to another issue. We need a
"chair" to decide what to do.
- 20:30:18 [IanTAG-MI]
- TB: Do we have consensus emerging that we could assert that a level
of indirection is desirable?
- 20:30:37 [IanTAG-MI]
- TBL: I wouldn't say desirable. But it should be available.
- 20:30:51 [IanTAG-MI]
- TBL: I won't tell people to use indirection if they only have one
thing.
- 20:31:05 [IanTAG-MI]
- TBL Summarizing:
- 20:31:16 [IanTAG-MI]
- * It is good to put a description of what you have at the end of a
namespace URI.
- 20:31:29 [IanTAG-MI]
- No other resolution at this time.
- 20:31:54 [IanTAG-MI]
- IJ: I think we can add "Having indirection available is useful."
- 20:32:59 [TimBL]
- If everything you have will fit in ine file, then we suggest you
prodcue that.
- 20:33:13 [IanTAG-MI]
- DO: What about we provide a template for when you only have one
schema (one thing at the end of the URI).
- 20:34:14 [IanTAG-MI]
- TBL on IJ's point: No, having indirection available when you have
only one thing is not required.
- 20:35:07 [IanTAG-MI]
- --------------------------------------
- 20:35:17 [IanTAG-MI]
- Resolving issues
- 20:35:30 [TimBL]
- http://www.w3.org/2001/tag/2002/0129-mime
- 20:37:15 [DanC]
- DanC has joined #tagmem
- 20:37:24 [IanTAG-MI]
- TBL: I'd like to discuss namespace-based dispatching.
- 20:37:31 [TimBL]
- It is acknowledged that there are exceptions to this rule, for
example XSLT documents whose root element's namespace depends on the
desired output from application of the XSLT.
- 20:37:43 [TimBL]
- "
- 20:37:52 [IanTAG-MI]
- TBL: I don't like exceptions to rules. We have to deal with them.
- 20:37:54 [TimBL]
- I feel we should fix that.
- 20:38:06 [IanTAG-MI]
- TB: There are cases where the root namespace is lying.
- 20:38:26 [IanTAG-MI]
- TBL: Two ways of looking at the XSLT case:
- 20:38:52 [IanTAG-MI]
- 1) This is not an xml document. This is an xslt document
(application/xslt). You cannot launch a generic xml system on it
because that would be misleading.
- 20:39:12 [IanTAG-MI]
- ...you run the document through an xslt processor and feed the output
back to your generic xml processor.
- 20:39:18 [PaulC]
- XSLT 1.0 states: The MIME media types text/xml and application/xml
[RFC2376] should be used for XSLT stylesheets. It is possible that a
media type will be registered specifically for XSLT stylesheets; if and
when it is, that media type may also be used.
- 20:39:28 [IanTAG-MI]
- 2) Or, this is a valid xml document and is therefore an xhtml
document.
- 20:40:08 [IanTAG-MI]
- SW: Comment on approach (1) - can the result of the processing yield
a mime type for the next stage.
- 20:40:14 [IanTAG-MI]
- TBL: XSLT does not give you a mime type....
- 20:40:28 [IanTAG-MI]
- NW: Yes, I think that you can provide a mime type in your output
method .
- 20:40:40 [IanTAG-MI]
- TB: We are only concerned with the case where the mime type isn't
useful, aren't we?
- 20:40:43 [IanTAG-MI]
- TBL: Yes.
- 20:40:57 [IanTAG-MI]
- (NW confirms that media type possible as part of output.)
- 20:41:29 [IanTAG-MI]
- NW: If we go this way, then we should talk to WGs about a requirement
to register a mime type for vocabularies they produce.
- 20:41:43 [IanTAG-MI]
- TBL: We've already recommend that WGs do this.
- 20:41:49 [IanTAG-MI]
- NW: It becomes *necessary*.
- 20:42:13 [IanTAG-MI]
- DO: Or: If the processor that will deal with this thing can't deduce
from the outermost element what to do, then you need to register a mime
type.
- 20:42:28 [IanTAG-MI]
- TB: I think that they should register a mime type for any xml
language.
- 20:44:59 [IanTAG-MI]
- TBL: When you consider plan (2), you start processing the xhtml
document, and at some point in the processing, when you get to the xslt
part, you call the plug-in. The plug-in may say "time out! give me the
whole document and I'll start again."
- 20:45:14 [IanTAG-MI]
- DO: That's not how it works today.
- 20:45:41 [IanTAG-MI]
- TBL: We're only talking about about the specific case of a doc that
starts with xhtml.
- 20:45:53 [IanTAG-MI]
- q+ TB
- 20:46:23 [Norm]
- q_
- 20:46:24 [Norm]
- q+
- 20:47:25 [IanTAG-MI]
- TBL: An xslt document is not an xml document since you don't use the
standard xml processor. I hear DO objecting to plan 2.
- 20:47:32 [IanTAG-MI]
- ..but his model sounds like plan 1.
- 20:47:45 [IanTAG-MI]
- TB: I agree with TBL on this one.
- 20:48:02 [IanTAG-MI]
- TB: I propose a resolution:
- 20:48:08 [IanTAG-MI]
- a) When you know what it is, send a media type.
- 20:48:31 [IanTAG-MI]
- b) When you don't know what it is, but you know it's xml, then
namespace-based dispatching is ok.
- 20:48:49 [TimBL]
- TB was agreeing with Plan 1
- 20:48:50 [IanTAG-MI]
- c) In cases where ns-dispatching is wrong, then thou shalt provide an
appropriate media type to ensure proper routing.;
- 20:49:08 [TimBL]
- TB also said htat "+xml+ was not appropoiraiet with XSLT, and I agree
with him there.
- 20:49:15 [IanTAG-MI]
- PC: So (c) is a subcase of (a). When you know it's xslt, send as
xslt.
- 20:49:31 [IanTAG-MI]
- TB: When the server knows that namespace-based dispatching will screw
things up, must send a media type.
- 20:49:49 [TimBL]
- DO: When the topmost ele is salt, then it is also ok to server as
application/xml
- 20:49:54 [TimBL]
- (i aggree)
- 20:50:08 [Norm]
- q?
- 20:50:11 [IanTAG-MI]
- TB: And specifically, in the case of xslt and xquery, you shouldn't
use the "+xml" suffix in cases where what comes out will look radically
different from what goes in. PHP probably also applies.
- 20:50:36 [IanTAG-MI]
- NW: We have bandied about the phrase "This is not xml." I find that
deeply disturbing.
- 20:51:01 [IanTAG-MI]
- TB: I think it is in fact XML. We shouldn't say "This is not
xml."
- 20:51:21 [IanTAG-MI]
- TB: But we should say it's not safe to process as plain xml, you
should send with mime type having +XML suffix.
- 20:51:39 [IanTAG-MI]
- TBL: The TAG is describing how you find what the semantics of a
document is (whereas the XML document describes the syntax).
- 20:51:44 [Norm]
- I had two points to make...
- 20:52:10 [IanTAG-MI]
- TBL: So, an xslt document is syntactically XML, because you can't
rely on the topmost element to find out "what the document is" you
can't describe it as an xml document from the point of view of
smeantics.
- 20:52:24 [IanTAG-MI]
- NW: There seems to be agreement that:
- 20:52:59 [IanTAG-MI]
- a) The fully qualified name of the root element is necessay and
sufficient for determining what the document is. I am uncomfortable
with that. Am I the only one?
- 20:53:04 [IanTAG-MI]
- TBL: I'm saying:
- 20:53:37 [IanTAG-MI]
- - To know what a document means, you take the outermost element and
go to the spec that defines that element, which will tell you what to
do.
- 20:53:51 [PaulC]
- Can Norm explain why he is uncomfortable?
- 20:53:53 [IanTAG-MI]
- SW: I"m also slightly uncomfortable with TBL's assertation about the
topmost element.
- 20:54:09 [IanTAG-MI]
- TB: I don't feel comfortable talking about meaning.
- 20:54:12 [IanTAG-MI]
- IJ: I am not either.
- 20:54:17 [Norm]
- Not off the top of my head, PaulC, but I'll be thinking about it
- 20:54:48 [IanTAG-MI]
- TBL: The TAG will not tell you what software to run. So at the end of
the day, everything is couched in what a document means.
- 20:54:53 [PaulC]
- Is there a concrete change proposal to http://www.w3.org/2001/tag/2002/0129-mime
on the table?
- 20:55:20 [IanTAG-MI]
- NW: Are we implicitly saying something about documents that don't
have a toplevel namespace?
- 20:55:39 [IanTAG-MI]
- TBL: Right. In the Web architecture, if you don't include a
namespace, you're not being helpful.
- 20:56:08 [IanTAG-MI]
- TBL: If there is no namespace, the web architecture doesn't help you
with any meaning it might have.
- 20:56:50 [IanTAG-MI]
- TBL: For XML - if there is no namespace, the web architecture doesn't
help you with any meaning it might have.
- 20:57:56 [IanTAG-MI]
- TB: Let's rewrite "It is acknowledged that there are exceptions to
this rule, for example XSLT documents whose root element's namespace
depends on the desired output from application of the XSLT.
- 20:57:56 [IanTAG-MI]
- " to say "When namespace-based dispatching is not possible, it's
required that media types be provided and that they not end in +xml if
the version that's generated is not the version that was shipped."
- 20:58:07 [IanTAG-MI]
- TBL: We should give explicit instructions about what to do with
xslt.
- 20:58:35 [IanTAG-MI]
- TBL: We have encouraged people to dispatch on namespaces. We should
point out the specific case of xslt (and xquery).
- 20:58:44 [IanTAG-MI]
- TB: And 375 server-side include scripting languages.
- 20:59:31 [IanTAG-MI]
- DO: Should all xslt documents have application/xslt as mime type?
- 21:00:03 [IanTAG-MI]
- TB: The point of xslt is that what comes out is not what came in. I
think that even if the root element says its xslt, you should not label
as application/xml.
- 21:00:29 [IanTAG-MI]
- TBL: No processor, just because the mime type says "+xml" gives you
license to do link checking. All it allows you to do is look at the
outermost element.
- 21:01:26 [IanTAG-MI]
- TB: I think we are in agreement - there's a class of xml documents
where you can't process them in a generic xml way before applying some
other processing.
- 21:01:41 [IanTAG-MI]
- TBL: To me, generic XML processing means looking at outermost element
and looking to spec for meaning.
- 21:02:11 [IanTAG-MI]
- TB: Fortunately, we don't have to agree on that point. I think we can
agree that when unsafe, you need to send with some mime type other than
ending in +XML.
- 21:02:32 [IanTAG-MI]
- TB: Are we inconsistent with RFC3023?
- 21:03:11 [IanTAG-MI]
- TB: The argument that motivated "+xml" suffix is that there are
generic xml applications. I'm saying that if something is xslt, you
can't use "+xml" at the end.
- 21:03:35 [IanTAG-MI]
- http://www.ietf.org/rfc/rfc3023.txt
- 21:03:58 [IanTAG-MI]
- "Well-formedness and validity checking - An XML processor can
- 21:03:58 [IanTAG-MI]
- confirm that any XML document is well-formed and that it is valid
- 21:03:58 [IanTAG-MI]
- (i.e., conforms to its declared DTD or Schema).
- 21:03:58 [IanTAG-MI]
- "
- 21:04:38 [IanTAG-MI]
- TBL: We have a lot of things (e.g., programming languages) that
people are writing in XML.
- 21:06:37 [IanTAG-MI]
- TBL: Are there properties that TB has indicated that he'd like to use
to categorize and put on the Web, or not?
- 21:07:29 [TimBL]
- ping
- 21:07:31 [PaulC]
- Further to the question about whether an XSL MIME type exists: RFC
3023 states "However, no content type has yet been registered for
- 21:07:32 [PaulC]
- XSLT and so this media type should not be used until such
- 21:07:32 [PaulC]
- registration has been completed.
- 21:07:41 [IanTAG-MI]
- TB: I believe that as rfc3023 asserts, there are such things as
generic xml applications.
- 21:08:21 [IanTAG-MI]
- TB: I hadn't realized that the +xml suffix was potentially
harmful.
- 21:09:54 [IanTAG-MI]
- TB: You might want to tell software "Even though this is xslt, please
use a generic xml processor."
- 21:10:09 [IanTAG-MI]
- DO: Two issues:
- 21:10:28 [IanTAG-MI]
- 1) In the case where you can do dispatch based on root element,
should there be a mime type for it.
- 21:10:55 [IanTAG-MI]
- 2) Do all xslt documents have to have some content type, or only when
the content is "dangerous".
- 21:10:58 [PaulC]
- q+
- 21:11:05 [IanTAG-MI]
- q=PaulC
- 21:11:22 [IanTAG-MI]
- DO second question: What should the content type be?
- 21:11:46 [IanTAG-MI]
- PC: Everyone around the table believes that we should be forcing
everyone that does a namespace that qualifies the root element should
have to register in a central registry?
- 21:11:56 [IanTAG-MI]
- TB: We only said for W3C specifications.
- 21:12:49 [IanTAG-MI]
- TBL: What I'm saying is that a spec should define semantics and
syntax of a document. The XML spec (hereby elaborated) says that the
semantics of the xml document are defined by the outermost element.
- 21:13:10 [IanTAG-MI]
- TBL: I think this is always the case.
- 21:13:56 [IanTAG-MI]
- TBL: Do you have an alternative model?
- 21:14:11 [IanTAG-MI]
- PC: I'm trying to understand what we would tell people in w3c to do
w.r.t. rfc 3023.
- 21:14:32 [IanTAG-MI]
- TB: Draft finding is that w3c groups must register mime types (and
include in appendix in a spec).
- 21:14:53 [IanTAG-MI]
- PC: How is it that web arch works today and we are years into
xslt?
- 21:15:02 [IanTAG-MI]
- TB: Because xslt documents are not served as xslt.
- 21:15:19 [IanTAG-MI]
- ...what usually happens is that you dereference a URI that serves up
html.
- 21:15:44 [IanTAG-MI]
- NW: People do client-side xslt transformations in IE.
- 21:16:06 [IanTAG-MI]
- TB: This is in fact a corner case (what we've been talking
about).
- 21:16:38 [IanTAG-MI]
- TB: Note "should" in "W3C Working Groups engaged in defining a
language should arrange for the registration of a media type for that
language."
- 21:16:54 [IanTAG-MI]
- PC: We should explain why the "should" is there and not "must".
- 21:17:08 [IanTAG-MI]
- ...and we should explain the case when you don't have to register the
mime type.
- 21:17:20 [IanTAG-MI]
- TBL: I understand that there are 3 ways to serve xslt.
- 21:17:48 [IanTAG-MI]
- a) Serve as xslt. Then processor generates output and reprocesses
generated content.
- 21:18:12 [IanTAG-MI]
- .....
- 21:18:39 [IanTAG-MI]
- IJ Summarizing TBL: The only way I see people using it is to include
a processing instruction that says "This is to be processed as
xslt."
- 21:19:14 [IanTAG-MI]
- TB: There's very little client-side processing of xsl.
- 21:19:21 [IanTAG-MI]
- TB: We are talking about rare cases.
- 21:19:40 [IanTAG-MI]
- DO: I think there are other cases out there (e.g., xml
encryption).
- 21:19:53 [IanTAG-MI]
- TB: Yes, this will happen again (e.g., xquery).
- 21:21:30 [IanTAG-MI]
- TB: I am reluctant to say that "Namespaces imply meaning." I may be
convinced of that, but it will require time.
- 21:22:12 [IanTAG-MI]
- TBL summarizing proposal:
- 21:22:29 [IanTAG-MI]
- - What an xml document means involves first looking up topmost
element in spec.
- 21:23:14 [IanTAG-MI]
- TBL: Either you agree that this means what I said, or you don't:
"Because of this, the namespace of the root element of an XML document
has special status and serves naturally as a basis for top-level
software dispatching in the case where the dispatch information is not
externally supplied.
- 21:23:15 [IanTAG-MI]
- "
- 21:23:17 [IanTAG-MI]
- TBL: This is fuzzy.
- 21:23:18 [PaulC]
- Since SHOULD is usually defined as "This word means that there may
exist valid reasons not to treat this item as a requirement, but the
full implications should be understood and the case carefully weighed
before discarding this item.
- 21:23:54 [PaulC]
- Paul ... I think our finding needs to define the "valid reasons" not
to do this or at least give an example.
- 21:24:01 [IanTAG-MI]
- TBL: I would rather say "is definitively" instead of "has special
status". No other namespaces have any use for dispatching software
until you have processed the toplevel element.
- 21:25:12 [IanTAG-MI]
- IJ: I think we are stuck between TBL's attempts to convey author's
meaning most clearly, and TB has special cases where he wants to find
other meaning than the author's.
- 21:25:41 [IanTAG-MI]
- TBL: But that still relies on you knowing the toplevel element - to
know that you can get useful information by trawling.
- 21:26:01 [IanTAG-MI]
- TB: I disagree.
- 21:26:18 [IanTAG-MI]
- TBL: I think that what TB says works for a subset of documents, but
not in the general case.
- 21:26:32 [IanTAG-MI]
- TBL: I'm worried about cases like quoting of other documents.
- 21:27:07 [IanTAG-MI]
- ..there are cases like this all over the semantic Web.
- 21:27:21 [PaulC]
- Before we approve this finding I think we need to check that every
"should" is exactly what we want.
- 21:27:50 [IanTAG-MI]
- TB: Check out "Correct dispatching and processing requires context -
in general it is not reasonable nor safe to do namespace-based
processing without knowledge of the namespace of ancestor elements.
- 21:27:51 [IanTAG-MI]
- "
- 21:28:03 [IanTAG-MI]
- TB: I'm resisting going further and saying you can never do anything
else.
- 21:28:08 [IanTAG-MI]
- TBL: And yet I would like to go there.
- 21:29:43 [IanTAG-MI]
- Action TBL: Propose alternative wording to the section
"Namespace-based dispatching"
- 21:30:46 [IanTAG-MI]
- TBL: I will edit http://www.w3.org/2001/tag/2002/0129-mime
and add alternative text.
- 21:30:51 [IanTAG-MI]
- --------------------------
- 21:30:51 [IanTAG-MI]
- Break
- 21:43:22 [IanTAG-MI]
- IJ Proposal:
- 21:43:58 [IanTAG-MI]
- a) The only guarantee for getting meaning of document is processing
topmost element and then recursively.
- 21:44:16 [IanTAG-MI]
- b) Any other processing is not guaranteed to convey that meaning.
- 21:45:10 [IanTAG-MI]
- TBL: I would rather say for (b) no other processing has any defined
meaning.
- 21:45:25 [PaulC]
- q+
- 21:45:34 [TimBL]
- ack p
- 21:46:00 [IanTAG-MI]
- PC: I think the first thing we have to do is to get something written
so that people can respond "yes" or "no".
- 21:46:12 [IanTAG-MI]
- PC: Do "should"s in proposed findings actually mean "should"?
- 21:46:35 [IanTAG-MI]
- PC: We need to define our terminology (e.g., "Should").
- 21:47:06 [IanTAG-MI]
- PC: We should give examples of counter reasons why one would not do
something.
- 21:47:22 [IanTAG-MI]
- ...if we can't find counter reasons, then we should say must.
- 21:49:12 [IanTAG-MI]
- TBL: Where there's a should, there's a trade-off. I agree, we should
include the "Unless" cases.
- 21:49:26 [IanTAG-MI]
- ...do a cost-benefit analysis.
- 21:50:51 [IanTAG-MI]
- PC: Since we know that our findings contradict something an existing
WG has done, we should point out why we think that this is a mistake,
and should be rectified.
- 21:51:17 [IanTAG-MI]
- From our charter:
- 21:51:27 [IanTAG-MI]
- "As part of coordination with other groups producing Architectural
Recommendations, TAG deliverables will acknowledge the timing and
historical perspective of existing Web technologies.
- 21:51:27 [IanTAG-MI]
- "
- 21:52:32 [IanTAG-MI]
- PC: I think s/should/must in "The consequence is that server-side
applications should ensure that for XML resources, they supply a
charset header only where there is complete certainty as to the
encoding in use, since an error will cause a perfectly usable resource
to be rejected by an architecturally sound client.
- 21:52:32 [IanTAG-MI]
- "
- 21:53:45 [TimBL]
- s/MUST
- 21:53:50 [IanTAG-MI]
- PC: As I commented before, I think we need to tighten this up
more.
- 21:54:42 [IanTAG-MI]
- TBL: Shouldn't we be able to have working documents in the TOC?
- 21:55:44 [IanTAG-MI]
- PC: What time period should we expect to ask for comments within when
we send this out?
- 21:56:09 [IanTAG-MI]
- ...I'd like to get this done by next week's meeting. Suppose we
announce on the 21st and welcome commentary until a particular
date.
- 21:57:08 [IanTAG-MI]
- TB: I suggest a 2-week period and see how that works.
- 21:57:13 [IanTAG-MI]
- TB: Suppose we publish this in the toc.
- 21:57:39 [IanTAG-MI]
- ...for each paragraph that we have in there, I think we should have a
header of when published, whether it's final, etc. What happens after
two weeks?
- 21:57:54 [IanTAG-MI]
- PC: I suggest different status labels: proposed, draft, final.
- 21:58:11 [IanTAG-MI]
- ...let's start with those three stages.
- 21:58:34 [IanTAG-MI]
- PC: We should also have a phase "open".
- 21:58:53 [IanTAG-MI]
- TBL: I think it's important to be able to plug issues into the toc,
whether or not we've resolved them.
- 22:00:27 [IanTAG-MI]
- TBL: I don't want to use "proposed" (sounds like PR).
- 22:01:35 [IanTAG-MI]
- TBL: I propose "not finished writing", "please comment on this", "we
think we're done and will put into a document"
- 22:03:11 [IanTAG-MI]
- Action TBL: Resolve the "shoulds".
- 22:03:19 [IanTAG-MI]
- Action IJ: Integrate into TOC
- 22:03:46 [IanTAG-MI]
- (and unlink the draft findings from tag home page and link to toc
instead.)
- 22:03:57 [IanTAG-MI]
- TB: Also explain a little how the toc will evolve.
- 22:04:22 [IanTAG-MI]
- IJ: I will make the toc start to look like a W3C tech report.
- 22:04:27 [IanTAG-MI]
- (Thumbs up from TB and PC)
- 22:04:51 [IanTAG-MI]
- ----------------------------------
- 22:05:23 [IanTAG-MI]
- uriMediaType-9: Why does the Web use mime types and not URIs?
- 22:05:35 [IanTAG-MI]
- http://www.w3.org/2001/tag/ilist#uriMediaType-9:
- 22:05:47 [IanTAG-MI]
- TB: Have people read Eastlake's proposal?
- 22:06:19 [IanTAG-MI]
- http://www.ietf.org/internet-drafts/draft-eastlake-cturi-03.txt
- 22:07:09 [TimBL]
- Zakim, have you read it?
- 22:07:10 [Zakim]
- I don't understand your question, TimBL.
- 22:07:42 [IanTAG-MI]
- TBL: I would prefer an http URI.
- 22:08:10 [IanTAG-MI]
- The IANA registry is getting better, I grant you.
- 22:08:39 [TimBL]
- http://www.iana.org/numbers.html
- 22:09:15 [IanTAG-MI]
- TBL: We could either ask IANA to allocate a dns name to a persistent
registry.
- 22:09:25 [TimBL]
- content-type:
- 22:09:28 [TimBL]
- should be
- 22:09:47 [TimBL]
- http://registry.iana.org/content-type
- 22:10:54 [IanTAG-MI]
- TBL: This has cropped up in xml canonicalization.
- 22:11:13 [PaulC]
- see http://lists.w3.org/Archives/Public/uri/2001Jan/0006.html
for commentary on Eastlake draft
- 22:11:31 [IanTAG-MI]
- (from Larry Masinter)
- 22:11:41 [IanTAG-MI]
- TB: I agree that an HTTP URL would be much better.
- 22:12:01 [IanTAG-MI]
- Resolved: An HTTP URL would be better than content-type:
- 22:12:27 [IanTAG-MI]
- Action SW: Write up that we approve of the Don Eastlake draft with
"http:" instead of "content-type:".
- 22:12:39 [IanTAG-MI]
- ..and that the internet should commit to the maintenance of this
registry.
- 22:12:45 [IanTAG-MI]
- TB: In RDDL we do this as well.
- 22:13:01 [IanTAG-MI]
- ..for content types that are not xml, we make a URI out of their
media types in the way that masinter says.
- 22:13:51 [PaulC]
- Original requirement in http://lists.w3.org/Archives/Public/uri/2001Jan/0008.html
"I'm not sure what requirement Don Eastlake was looking at; the problem
that got the rest of us going was the proposal that CCPP (http://www.w3.org/Mobile/CCPP/)
use URIs to identify media features and similar elements.
- 22:14:33 [IanTAG-MI]
- TB Proposed: Lets adopt a position that for namespace names, URNs
should not be used.
- 22:14:35 [TimBL]
- URNs should not be used for namespace names
- 22:14:39 [IanTAG-MI]
- TBL Seconds.
- 22:15:14 [PaulC]
- For Dan C's view on this thread see http://lists.w3.org/Archives/Public/uri/2001Jan/0010.html
- 22:15:57 [IanTAG-MI]
- SW: Was there good reason in the namespaces spec for allowing URI
references?
- 22:16:46 [PaulC]
- Can we please try not to start dealing with somewhat orthongonal
issues. Let's table the question for future review and stick to our
agneda.
- 22:16:50 [IanTAG-MI]
- TBL: Might have been done to allow relative URIs.
- 22:18:04 [IanTAG-MI]
- Action TB: Write up a proposal to suggest that URNs not be used for
namespace URIs.
- 22:20:00 [IanTAG-MI]
- --------------------------------
- 22:20:05 [IanTAG-MI]
- namespaceDocument-8: What should a "namespace document" look
like?
- 22:20:12 [IanTAG-MI]
- TBL: We've stalled on this one.
- 22:20:15 [IanTAG-MI]
- -------------------------------------------
- 22:20:27 [IanTAG-MI]
- rdfmsQnameUriMapping-6: Algorithm for creating a URI from a
QName?
- 22:20:31 [IanTAG-MI]
- TB: Ugh, this one has hair on it.
- 22:20:33 [IanTAG-MI]
- -------------------------------------------
- 22:20:41 [IanTAG-MI]
- whenToUseGet-7:
- 22:20:48 [IanTAG-MI]
- 1. GET should be encouraged, not deprecated, in XForms
- 22:21:14 [IanTAG-MI]
- TBL: I think that the XForms WG didn't have any force behind decision
to deprecate GET, so this part is done.
- 22:21:17 [IanTAG-MI]
- 1. How to handle idempotent queries (New POST-like method? GET plus a
body?)
- 22:22:00 [IanTAG-MI]
- TBL: I propose we right this up as a hole in the architecture - the
parameters are ridiculous to represent as an identifier, but it's
nonetheless idempotent. There should be something just like POST but
with QUERY to tell the proxy that there are no side effects.
- 22:22:10 [IanTAG-MI]
- PC: Is this a new requirement on HTTP?
- 22:22:36 [IanTAG-MI]
- TBL: Yes. The Arch principle is that, if what you are doing has no
side effects, under the visibility of "rest" you should use an HTTP
method that has no side effects.
- 22:23:07 [IanTAG-MI]
- ...we note that there is a hole in the HTTP spec since for processing
of large quantities of data, there is no suitable method. A logical
solution is to make an HTTP Query method.
- 22:24:05 [PaulC]
- And who do we direct this recommendation to?
- 22:24:38 [IanTAG-MI]
- TBL: Ask Philipp Hoschka to put on the agenda of the IETF liaison
call.
- 22:25:37 [IanTAG-MI]
- Action TBL:
- 22:25:39 [IanTAG-MI]
- - Take this to PH.
- 22:25:47 [IanTAG-MI]
- - Add a couple of sentences to the arch doc toc.
- 22:26:24 [IanTAG-MI]
- PC: If such an HTTP request existed, would XForms use it?
- 22:26:26 [IanTAG-MI]
- TB, TBL: YEs.
- 22:26:38 [IanTAG-MI]
- PC: Then important to communicate this finding to the xforms wg as
well.
- 22:27:24 [IanTAG-MI]
- TB: This is not just theory. If we can get the right people to sign
off on this, it would be easy to implement and we would have a fair
amount of buy-in.
- 22:27:42 [IanTAG-MI]
- TBL: We definitely have to take this to the IETF.
- 22:27:58 [IanTAG-MI]
- ActIon TBL:
- 22:28:02 [IanTAG-MI]
- - Include xforms wg in the loop.
- 22:28:06 [PaulC]
- we're working on getting A/V help
- 22:29:54 [IanTAG-MI]
- -------------------------------------
- 22:30:00 [IanTAG-MI]
- rdfmsQnameUriMapping-6: Algorithm for creating a URI from a
QName?
- 22:30:08 [IanTAG-MI]
- Raised here: http://lists.w3.org/Archives/Public/www-tag/2002Jan/0178
- 22:30:18 [IanTAG-MI]
- Captured here: http://www.w3.org/2000/03/rdf-tracking/#rdfms-qname-uri-mapping
- 22:30:51 [IanTAG-MI]
- TBL: Let's not look at this now.
- 22:30:54 [IanTAG-MI]
- -------------------------------------------------
- 22:31:09 [IanTAG-MI]
- Action item review:
- 22:31:22 [IanTAG-MI]
- TBL: Are people happy with the access they have to the web site?
- 22:31:26 [IanTAG-MI]
- NW: I have it.
- 22:32:10 [IanTAG-MI]
- IJ: There is no limit to NW's access to the W3C site.
- 22:32:25 [IanTAG-MI]
- TBL: Anyone else want cvs access?
- 22:32:49 [IanTAG-MI]
- SW, TB: Just fine sending stuff to Ian.
- 22:33:01 [IanTAG-MI]
- PC: I may ask for cvs access later.
- 22:33:12 [IanTAG-MI]
- TBL: I claim my action item is done.
- 22:33:15 [IanTAG-MI]
- --------
- 22:33:21 [IanTAG-MI]
- RF: Summarize different approaches currently used for mapping URIs to
media types.
- 22:33:25 [IanTAG-MI]
- Status: Not done.
- 22:33:48 [IanTAG-MI]
- TBL: I think we've dealt with this by reading Don Eastlake spec. I
propose we obsolete RF's action.
- 22:33:59 [IanTAG-MI]
- Status: Chair closes action item.
- 22:34:14 [TimBL]
- ------------------------------------------------------------
- 22:34:24 [TimBL]
- Any more Issues?
- 22:35:04 [IanTAG-MI]
- Chair changes Status of RF action to "pending"
- 22:35:05 [IanTAG-MI]
- -----------------------
- 22:35:07 [IanTAG-MI]
- Issues?
- 22:38:29 [IanTAG-MI]
- [[[
- 22:38:30 [IanTAG-MI]
- A discussion on www-tag starting at http://lists.w3.org/Archives/Public/www-tag/2002Jan/0019
developed into some interesting discourse on what a next rev of XML
might look like. Following on this, a thought experiment named XML-SW
appears at
- 22:38:30 [IanTAG-MI]
- ]]]
- 22:38:30 [IanTAG-MI]
- -- www-tag@w3.org from February 2002: XML-SW, a thought
experiment
- 22:38:31 [IanTAG-MI]
- http://lists.w3.org/Archives/Public/www-tag/2002Feb/0031.html
- 22:38:35 [IanTAG-MI]
- Fri, 08 Feb 2002 12:34:39 GMT
- 22:38:37 [IanTAG-MI]
- TB: I request that the TAG not take this up.
- 22:38:55 [IanTAG-MI]
- PC: This is a valuable piece of work. What should we do with it?
- 22:39:31 [IanTAG-MI]
- DO: Take to the XML Core WG.
- 22:39:37 [IanTAG-MI]
- PC: Yes, I forwarded this to the CG.
- 22:39:46 [IanTAG-MI]
- TBL: Sounds like it's been sent to the proper place.
- 22:39:58 [IanTAG-MI]
- TBL: Why didn't you take out processing instructions?
- 22:40:12 [IanTAG-MI]
- NW: Please read threads on www-tag about this.
- 22:41:27 [PaulC]
- http://lists.w3.org/Archives/Public/www-tag/2002Feb/0031.html
is Tim's note on XML-SW
- 22:41:49 [PaulC]
- XML-SW = XML 1.0 2nd ed.
- 22:41:50 [PaulC]
- - DTDs (and therefore entities)
- 22:41:50 [PaulC]
- + namespaces
- 22:41:50 [PaulC]
- + xml:base
- 22:41:50 [PaulC]
- + the infoset.
- 22:42:30 [IanTAG-MI]
- Resolved: Add xml-sw-10 to the issues list. TAG will not address.
Already forwarded to CG.
- 22:42:33 [TimBL]
- Zakim, who is here
- 22:42:34 [Zakim]
- TimBL, you need to end that query with '?'
- 22:42:43 [TimBL]
- Zakim, who is here?
- 22:42:44 [Zakim]
- I see MIT
- 22:42:45 [Zakim]
- MIT has Ian, TimBL, Norm, Stu
- 22:43:43 [IanTAG-MI]
- ---------------------------------
- 22:43:59 [PaulC]
- http://lists.w3.org/Archives/Public/www-tag/2002Feb/0044.html
- 22:44:21 [IanTAG-MI]
- "I would like to raise the issue of what is the appropriate
relationship
- 22:44:22 [IanTAG-MI]
- between SOAP RPC and the web's reliance on URIs. In particular, what
are
- 22:44:22 [IanTAG-MI]
- best practices for putting information in SOAP RPC parameters versus
in
- 22:44:22 [IanTAG-MI]
- the endpoint URI. If the TAG considers it important I would like to
have
- 22:44:22 [IanTAG-MI]
- a canonical answer that could be added to the SOAP specification.
- 22:44:23 [IanTAG-MI]
- ""
- 22:44:56 [IanTAG-MI]
- PC: This should be dealt with first in XML Protocol WG.
- 22:45:03 [IanTAG-MI]
- SW: David Fallside has picked this up.
- 22:46:10 [IanTAG-MI]
- Resolved: Add soapRPCURI-11. Declined and sent to XML Protocol
WG.
- 22:46:11 [PaulC]
- http://lists.w3.org/Archives/Public/www-tag/2002Feb/0054.html
for Rick Jelliffe's concerns about XML 1.1
- 22:46:36 [IanTAG-MI]
- (URI from fallside: http://lists.w3.org/Archives/Public/www-tag/2002Feb/0056.html)
- 22:46:39 [IanTAG-MI]
- -----------------------------------
- 22:46:45 [IanTAG-MI]
- http://lists.w3.org/Archives/Public/www-tag/2002Feb/0054.html
for Rick Jelliffe's concerns about XML 1.1
- 22:47:17 [IanTAG-MI]
- TB: I tend to agree with most of RJ's points. I disagree with some of
the directions core is going with 1.1.
- 22:47:25 [IanTAG-MI]
- TB: I'm not sure that this is for the TAG.
- 22:48:01 [IanTAG-MI]
- TB: There's a process issue - I was at the Unicode conf a few weeks
ago. Discussion of this topic at lunch. I was enlightened just talking
to the Unicode folks.
- 22:48:07 [IanTAG-MI]
- ...it turns out that:
- 22:48:16 [IanTAG-MI]
- a) It's hard to know what the right thing to do it.
- 22:48:24 [IanTAG-MI]
- b) It's hard to know how one would implement the right thing.
- 22:48:38 [IanTAG-MI]
- TB: In my opinion, the current XML Core WG badly needs more external
input than they've got so far.
- 22:49:13 [PaulC]
- Paul Grosso has taken up Rick's email with the XML CG.
- 22:49:25 [IanTAG-MI]
- NW: The core WG may need more external input, but it's not carrying
out its work in secret.
- 22:49:29 [Stuart]
- David Fallside's response to Paul Precod's issues is at: http://lists.w3.org/Archives/Public/www-tag/2002Feb/0056.html
- 22:49:32 [PaulC]
- q+
- 22:50:04 [TimBL]
- ack paul after TimBray
- 22:50:06 [IanTAG-MI]
- TB: I'm concerned that some important discussions have not occurred
within the XML Core WG.
- 22:50:19 [IanTAG-MI]
- ...there are some important viewpoints not at the table and this
worries me.
- 22:50:31 [Norm]
- ping?
- 22:50:59 [IanTAG-MI]
- pong
- 22:51:20 [IanTAG-MI]
- PC: Good sign that xml core wg asking I18N WG for input.
- 22:51:51 [IanTAG-MI]
- DO Proposed:
- 22:51:57 [IanTAG-MI]
- - We've looked at issue. Not in our purview.
- 22:52:07 [IanTAG-MI]
- - Glad to see that core WG is looking at the issue with I18N
input.
- 22:53:03 [IanTAG-MI]
- TBL quoting RJ:
- 22:53:15 [IanTAG-MI]
- "That the Core WG feel free to ignore constraints coming in from
IETF, Unicode,
- 22:53:16 [IanTAG-MI]
- and the existing technologogical base, shows a serious problem with
either the XML 1.1 Requirements document, which does not mention the
outside world, or with the Core WG's understanding of how an
interchange technology such as XML operates: that maximum compatibility
is essential.
- 22:53:16 [IanTAG-MI]
- "
- 22:53:34 [IanTAG-MI]
- TBL: We are making the assumption that the XML Core WG is now being
more responsive.
- 22:54:24 [IanTAG-MI]
- PC: Caution about referring to Member-only messages on public
list.
- 22:54:52 [IanTAG-MI]
- Action DO:
- 22:55:20 [IanTAG-MI]
- DO: - Ping Misha and Martin and say "please copy this message to the
IG so that I can quote it in a TAG reply to Rick Jelliffe"
- 22:56:09 [IanTAG-MI]
- TBL: Do you think we should have a separate status for our issues
where we think we're done, but we want to track what others are
supposed to do. Pending "on someone else."
- 22:57:31 [IanTAG-MI]
- ?
- 22:58:12 [IanTAG-MI]
- TB: I think that we have taken a finding that at this time, this
issue is not appropriate for TAG consideration. Full stop.
- 22:58:19 [IanTAG-MI]
- IJ: Seconded.
- 22:58:51 [IanTAG-MI]
- PC: I suggest that at tech plenary, NW talk about this method of
working:
- 22:59:18 [IanTAG-MI]
- - If TAG declines an issue and they are not satisfied with the result
of handing it off, feel free to bring it back to us. But we won't
continue to track it.
- 23:00:35 [IanTAG-MI]
- -------------------
- 23:00:39 [IanTAG-MI]
- customMediaType-2: RFC 3023 flawed?
- 23:00:43 [IanTAG-MI]
- http://lists.w3.org/Archives/Public/www-tag/2002Feb/0017.html
- 23:00:52 [IanTAG-MI]
- TB: This falls into earlier findings.
- 23:01:39 [IanTAG-MI]
- ...existing findings cover this (especially if changing from should
to must)
- 23:02:19 [IanTAG-MI]
- ------------------------------------------------------
- 23:03:12 [IanTAG-MI]
- TBL: I propose that the threads be a living document:
- 23:03:18 [IanTAG-MI]
- http://www.w3.org/2002/02/04-tag#threads
- 23:05:53 [PaulC]
- we are having a problem with our video link - can you see us?
- 23:06:03 [PaulC]
- we are redialing.
- 23:07:02 [IanTAG-MI]
- ----------------------------
- 23:07:03 [PaulC]
- we are BACK!
- 23:07:32 [IanTAG-MI]
- TB: Let's go to admin issues....
- 23:07:37 [IanTAG-MI]
- -----------------------------------------
- 23:07:54 [IanTAG-MI]
- "How did this format of meeting go?
- 23:07:54 [IanTAG-MI]
- "
- 23:08:17 [IanTAG-MI]
- DO: I thought this worked great.
- 23:08:42 [IanTAG-MI]
- TB: Certain aspects were irritating, but we dealt with them well. I
think we should still make an effort to all be in one room.
- 23:10:09 [IanTAG-MI]
- PC: We need to do more advance planning for scheduling next ftf
meeting.
- 23:10:35 [IanTAG-MI]
- TB: I suggest picking next meeting date by email in September.
- 23:10:44 [IanTAG-MI]
- TB: I offer to host in Vancouver.
- 23:12:01 [IanTAG-MI]
- IJ: What about a 2-day meeting?
- 23:12:15 [IanTAG-MI]
- PC: I'm easy.
- 23:13:31 [IanTAG-MI]
- Proposed TBL: 24-25 September
- 23:16:36 [IanTAG-MI]
- "Real face-to-face"
- 23:17:07 [IanTAG-MI]
- Proposed: One day around Nov 2002 ac meeting in Cambridge.
- 23:20:41 [IanTAG-MI]
- Proposed: 18 November (during AC intro day, but in light of
experience in Hawaii)
- 23:21:48 [IanTAG-MI]
- Action IJ: Inform AB of our upcoming ftf meeting plan.
- 23:22:17 [IanTAG-MI]
- (and add dates to Member events calendar)
- 23:23:13 [IanTAG-MI]
- DO: We need a better white board.
- 23:27:06 [IanTAG-MI]
- ADJOURNED
- 23:28:14 [Zakim]
- -MIT
- 23:28:14 [Zakim]
- TAG_TAG f2f()10:00AM has ended