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