IRC log of tagmem on 2003-06-02

Timestamps are in UTC.

14:05:17 [RRSAgent]
RRSAgent has joined #tagmem
14:05:25 [tim-mit]
RRSAgent, pointer?
14:05:25 [RRSAgent]
14:08:31 [Norm]
Ian, hello?
14:09:52 [Ian]
zakim, call Ian-BOS
14:09:52 [Zakim]
sorry, Ian, I don't know what conference this is
14:09:56 [Ian]
zakim, this is TAG
14:09:56 [Zakim]
sorry, Ian, I do not see a conference named 'TAG'
14:10:05 [tim-mit]
Ian, we are NOT on Zakim
14:10:10 [Chris]
ian, dial direct
14:10:16 [Chris]
conf is not on zakim
14:11:26 [Norm]
yes 617-258-7910
14:12:15 [Ian]
Roll Call: SW, TB, TBL, NW, CL, IJ
14:12:42 [Ian]
Regrets: PC, DO
14:12:55 [Ian]
Missing: DC, RF
14:14:45 [Ian]
# Accept 27 May teleconference minutes?
14:17:06 [Ian]
Correction: Previous meeting 12 May.
14:17:13 [Ian]
No resolution on state of those minutes; held over.
14:18:20 [Ian]
Review of agenda:
14:19:06 [Ian]
Next meeting: Proposed 9 June (regular teleconf on Monday)
14:19:23 [Ian]
NW: Likely partial regrets (will be on West Coast)
14:19:33 [Ian]
Resolved: next meeting 9 June 2003
14:19:51 [DanC]
DanC has joined #tagmem
14:19:55 [Ian]
Next virtual teleconf scheduled for 19 June. Conflicts with DC, RF, SW, TB.
14:20:50 [Ian]
14:20:54 [Ian]
14:21:00 [Ian]
Feedback from Budapest.
14:21:12 [Ian]
CL: I think the AC session went well. Gave AC reps an idea of what we do.
14:21:48 [Ian]
CL: I suspect they feel more comfortable about the TAG.
14:21:54 [Ian]
CL: We did two straw polls.
14:22:18 [Ian]
Member-only slides:
14:22:32 [Ian]
CL: I think AC said they wanted arch doc both better and sooner.
14:22:53 [Ian]
TBL: For that question, I think people wanted us to cover historic Web, Sem Web, Web services, ...
14:23:11 [Ian]
TBL: I think our best course is to give them what we've got when we've got it.
14:23:25 [Ian]
SW: What about feedback on RDDL doc?
14:23:40 [Ian]
TB: I've received queries from Robin Berjon about future of RDDL.
14:24:08 [Ian]
TB latest version:
14:24:22 [Ian]
TB: Web3D folks interested in knowing about RDDL
14:25:15 [DanC]
14:25:18 [Ian]
SW: I heard from IJ that at least one suggestion was to publish as a Note, then take it from there.
14:25:45 [Roy]
Roy has joined #tagmem
14:27:28 [Ian]
DC, IJ: I don't remember much feedback to TAG presentation at WWW2003.
14:27:37 [Roy]
I've been trying to get into the telecon... what is the passcode?
14:27:45 [Ian]
IJ: other ideas:
14:27:55 [Ian]
- Allow people to register as customers of an issue.
14:28:22 [Roy]
14:28:38 [Ian]
+ RoyF
14:29:58 [Ian]
14:30:21 [Ian]
[TAG looks at using VNC for collaboration during this meetnig]
14:31:14 [Stuart]
xvncviewer -shared
14:32:47 [Ian]
Read-through of Arch Doc
14:33:06 [Ian]
14:33:20 [Ian]
NW: My goal here is to walk through doc with eye to finding show-stoppers for last call.
14:34:08 [Ian]
NW: In particular, look at section 4.
14:35:04 [Ian]
TB: I sent comments on section 4:
14:35:15 [Ian]
[Lots of people read TB's proposal]
14:35:17 [DaveO]
DaveO has joined #tagmem
14:35:34 [Ian]
NW: I agree work with TB on getting this written.
14:37:12 [Ian]
[TAG gives up on vnc for now]
14:37:24 [Ian]
+ DO
14:37:50 [Ian]
CL: Section 4.3 Presentation/Content/Interaction is misplaced.
14:37:57 [Ian]
TB: There is content in the draft on this section.
14:38:07 [Ian]
TB: I thought it could be made to all out of 4.2.2 of my proposal.
14:38:17 [Ian]
TB: I wonder whether related to final form/re-usable.
14:38:25 [Ian]
CL: I've been working on a draft finding on this topic!
14:38:55 [Ian]
CL summarizes broadly: We seem to be making the arch doc more a summary doc and pointing to findings for detail.
14:39:05 [Ian]
NW: Seems reasonable to move content/presentation to 4.2.2
14:39:26 [Ian]
TB: I am willing to draft section 4 by end of week.
14:40:01 [Ian]
Looking at
14:41:47 [Stuart]
Reviewing TB Draft: Open endedness
14:41:47 [tim-mit]
tim-mit has joined #tagmem
14:43:47 [DanC]
see also: QA spec guidelines
14:43:54 [Stuart]
CL: add attention to authoers needs
14:44:12 [Norm]
that was me, actually, not that it matters
14:44:43 [Chris]
CL said 'availability of test suite' (and implementation report)
14:44:46 [Stuart]
TBL: Under 4.1.1 - formal specification/machine readable form
14:45:01 [DanC]
QA Framework: Specification Guidelines
14:45:01 [DanC]
W3C Working Draft 10 February 2003
14:45:15 [Stuart]
TB: that's what I'd intnded with attention to programmers' needs
14:46:05 [Stuart]
DO: Want to push back on the need for 4.1.1 on the basis that this is generic good spec wrinting characteristics
14:46:28 [Stuart]
CL: In think its useful and should be expanded.
14:46:54 [Stuart]
TBL/DC: The QA activity covers this.
14:47:10 [Stuart]
TB: Could go either way.
14:48:07 [Stuart]
CL: <scibe has lost thread>
14:48:33 [Stuart]
TB/CL: Does give us a place to put the error handling thing.
14:49:08 [Stuart]
TB: Want to avoid the 'debacle;' of RDF rewriting their own BNF for XML.
14:49:26 [Chris]
re - if XML, defined at the Infoset level
14:49:47 [tim-mit]
you mean XPath level?
14:50:16 [Chris]
make some of these 'good practice notes'
14:52:07 [Stuart]
TB:Action: write up a first draft of section 4 of Arch doc base on email:
14:52:54 [tim-mit]
PDF is better than PNG
14:52:59 [tim-mit]
gtom the point of view
14:53:11 [tim-mit]
[discussion of terms for 4.2.2]
14:53:26 [Stuart]
Discussion of Semantics v Presentation
14:53:45 [tim-mit]
from the point of view that you can index it, cut and paste text to a certian extent.
14:55:06 [Stuart]
CL: I'm working on a finding contentPresentation-26. Want to be sure we're headed in the same direction.
14:55:43 [DanC]
ah! 2 bits of writing. I see now.
14:55:52 [Stuart]
TB: I'm happy draft the whole section, and I'm happy to accept some paragraphs on Content/Presentation from Chriss
14:56:50 [DanC]
pointer to finding?
14:56:55 [Stuart]
TB: Makes sense to move 4.2.3 under 4.2.2
14:57:25 [Stuart]
DO: Extensibility issues? Composable or reusable bit?
14:57:57 [Chris]
14:58:15 [Chris]
14:58:17 [Stuart]
DO: Concrete example: Schema restriction if designing for extensibility. Deterministic/non-deterministic content models
14:58:54 [Stuart]
DO: Two types of composability: "backward compatible forward revision".
14:59:03 [Stuart]
CL: Sounds more like interop
14:59:40 [Stuart]
TB: Propose DO submits a couple of paragraphs to the group.
14:59:47 [tim-mit]
Backward compatability is an interesting discussion but big and long.
14:59:50 [Chris]
related issue for 4.2.3 is
14:59:51 [Stuart]
DO: Agrees
14:59:52 [tim-mit]
15:00:31 [Stuart]
Action DO: Write up a couple of paragraphs on extensibility for section 4.
15:01:51 [Stuart]
TBL: Designing languages for extensibility and backward comaptibility is very complicated. Maybe we need to get back to what URI's meand
15:02:03 [Stuart]
15:02:23 [DaveO]
15:02:51 [Stuart]
TBL: ... 1st thing we have to do is document 'how things work'.
15:02:57 [Stuart]
15:03:03 [Stuart]
ack tim
15:03:17 [Chris]
15:03:32 [Stuart]
ack Dave
15:03:58 [timbl]
- Extensability is a good thing
15:04:20 [timbl]
- If you use it distinuguish optional from mandatory extension
15:04:22 [Stuart]
DO: Think TBL is saying versioning is hard... shouldn't go there (for now)...
15:04:34 [timbl]
- For RDF, OWL provides powerful forwrad compatability tools
15:04:43 [Chris]
ack chris
15:04:47 [timbl]
15:04:52 [Stuart]
TB: Yep.. versioning is hard, multi dimensional and needs to be designed in up front.
15:05:02 [Stuart]
DO: <missed question>
15:05:15 [timbl]
DO: Don't tyou think there are sepcific features for this?
15:05:20 [Norm]
DO: Don't you think there are features in W3C specs to deal with this?
15:05:23 [Stuart]
TB: Anything defined in XML is more extensible/flexible
15:05:54 [Chris]
15:05:59 [DanC]
hmm... " Web Architecture: Extensible Languages"
15:06:07 [DaveO]
15:06:24 [timbl]
q+ to say the 3 "-" things which he typed in above.
15:06:30 [timbl]
q+ timbray
15:06:51 [Stuart]
SW: What expectations should we set wrt composablity of XML vocabs.
15:07:39 [Stuart]
TB: Yes we should say something about what folks should consider if thery want their langauages to composable and extensible
15:08:39 [Stuart]
TBL: Worth say that *if* you have extensibility to be able to distinguish between mandatory and optional extensionss
15:09:05 [Stuart]
TBL: OWL/SemWeb can describe the relationships between versions of things.
15:09:46 [DanC]
yes, the mandatory/optional bit is an architectural point that The Director has found wanting in a spec in the past; let's please document it clearly to prevent the sort of uncomfortable end-game stuff that happened before.
15:10:02 [Stuart]
DO: Ref to TBL design notes on mandatory/optional
15:11:29 [Stuart]
DO: I have a number of constituents for help on versioning, extensibility and evolution - larger community than those interested in resolving httpRange14
15:11:34 [timbl]
ack tim
15:11:43 [timbl]
ack chris
15:11:53 [timbl]
ack daveo
15:12:14 [timbl]
DanC, we cannt hear you at all
15:12:26 [timbl]
Who dropped?
15:12:50 [timbl]
We heard dialtime, ian
15:12:55 [timbl]
We heard dialtone, ian
15:13:24 [Stuart]
DC: Version in general is impossible... but maybe a few things worth saying. Leave space for versioning/extending; use URI as piviot points.
15:14:19 [Stuart]
DC: All sorts of mechanisms in Schema... but I don't know if there are any that really generalise.
15:14:51 [DanC]
... generalize to issues of web architecture.
15:15:39 [Chris]
q+ to talk about namespaces as opposed to namespace documents
15:15:49 [DanC]
ack danc
15:15:50 [Chris]
ack DanC
15:16:15 [DanC]
15:16:19 [DanC]
4.3.1. When to use XML
15:16:32 [Stuart]
Looking at 4.3.1 in WebArch doc "When to use XML"
15:17:00 [Stuart]
NW: Volunteered some text for 4.3.2
15:17:05 [Ian]
+ Ian on land line.
15:17:49 [Stuart]
CL: 4.3.2 starts of saying should use namespaces and then focusses on what should be in a namespace doc, rather than
15:18:20 [Stuart]
talking about why ns's should be used.
15:18:39 [Stuart]
NW: It's in the text I proposed.
15:18:58 [Stuart]
4.3.5 Complex XML with references to TAG issues
15:19:08 [Chris]
binary would go into the proposed 4.2.1 Binary vs. Textual
15:19:08 [Stuart]
CL: Move to ???
15:20:05 [Ian]
TB: I think 4.4 is a little long; would try to boil down.
15:20:15 [Ian]
CL: 4.4.1 in existing doc is rubbish
15:20:30 [Ian]
CL: I am expecting to replace section on content/presentation
15:21:04 [Ian]
TB: 4.4.1 disappears.
15:21:26 [Chris]
4.4.1 is notes about what to talk about later. some of it is already talked about
15:21:31 [Ian]
NW: I hear proposal that, for the purpose of advancing doc to last call, abandon 4.4.1 and rely on people to resurface issues discussed there in a more concrete form if they want them addressed.
15:21:37 [Ian]
[No objections to that course of action]
15:22:10 [Ian]
CL: Not ready for www-tag yet.
15:22:44 [Ian]
CL: I can commit to having this ready for www-tag next week.
15:23:00 [Ian]
[NW 4.5 arch doc]
15:23:05 [Chris]
kill 4.5. Ideas and issues
15:23:16 [Ian]
NW: This is a laundry list; sounds like we would be inclined to throw 4.5 in bit bucket.
15:23:27 [Ian]
TB: I don't see good solution to xlinkScope-23, item 8.
15:23:44 [Ian]
TB: Not sure where in the arch doc this belongs.
15:24:21 [Ian]
TB: I propose - new section 4.5 in my draft outline - "Hyperlinking in Resource Representations"
15:24:34 [timbl]
15:24:42 [Ian]
DC: Perhaps earlier in section 4 would be better (than 4.5)
15:25:03 [Ian]
DC: Rationale - links are the most important architectural piece for the Web. Should be earlier
15:25:18 [Ian]
CL: We need to put into the proposed section a difference between a URI and a link.
15:25:23 [timbl]
q+ to say that we should keep the issues from 45. in general
15:25:29 [timbl]
ack Chris
15:25:29 [Zakim]
Chris, you wanted to talk about namespaces as opposed to namespace documents
15:25:34 [Ian]
NW: How about just before TB's 4.2?
15:25:40 [Chris]
difference between a uri and a link needs to go in there
15:25:54 [Ian]
TB: Not convinced by DC; I think this document will not be accessed linearly.
15:26:05 [Ian]
ack Chris
15:26:17 [Ian]
ack timbl
15:26:17 [Zakim]
timbl, you wanted to say that we should keep the issues from 45. in general
15:26:48 [timbl]
15:26:54 [Ian]
IJ: What are other homes for items in 4.5?
15:27:05 [Chris]
so we decided to remove 4.5 but first find suitable homes for each point and it s associated link to an issue
15:27:20 [Ian]
TB: Perhaps another top-level section on mime type being authoritative?
15:27:25 [Ian]
IJ: Is that part of protocols or formats?
15:27:41 [Ian]
CL: Maybe mime type stuff for beginning of section 4
15:27:50 [Ian]
CL: And maybe needs a section title (for first few paragraphs)
15:28:07 [Ian]
TB: I'll think of a title for that section.
15:28:25 [Chris]
need a name for the 'representation is mime metadata plus the actual bits' section
15:28:43 [Ian]
Action NW: Take a stab at proposed new 4.5, wherever it ends up.
15:28:49 [Chris]
5. Machine-to-machine interaction
15:29:06 [Ian]
TB: I propose we leave 5 skeletal and delete 6.
15:29:25 [Ian]
TB: I think we won't have time to do much on 5 and get 4 more baked.
15:29:29 [Roy]
just "Interaction", please
15:29:55 [Ian]
TBL: I think that 5 is not about multi-modal interaction.
15:30:17 [Ian]
CL: I think so too, but don't know where to put 5.1 DI and MMI
15:30:29 [Ian]
DC: Nothing in section 5 that I can't live without.
15:30:37 [Ian]
TB: I think 5.2 is valuable.
15:30:47 [Ian]
RF: It just looks weird. :)
15:30:59 [Chris]
5.1. Device Independence and Multimodal Interaction needs to go in a 'Human to Machine interaction' section
15:31:15 [Chris]
maybee, some aspexcts of linking would also go in that section
15:31:28 [Chris]
Web is not static, so we need to deal with interaction
15:31:28 [Ian]
TBL: If we had something saying "Don't make protocol stateful when you can make it stateless" that would be reasonable.
15:33:21 [Ian]
[Discussion of what is scope of work about which we can declare victory]
15:33:33 [Ian]
TBL: You can make the last call "complete" by listing sections that are not baked.
15:33:35 [Stuart]
15:33:52 [timbl]
15:33:57 [Ian]
DC: The scope should be stated at the beginning of the doc. Don't require reader to read chapter 5 and fall off edge of earth.
15:34:25 [Ian]
NW: Propose - (1) Delete section 5 and (2) state in scope of doc that we don't cover this (3) List a few issues that we don't cover.
15:34:30 [Ian]
DC: Don't leave it there as a place-holder.
15:34:53 [Ian]
DC: The document should be complete for its chosen scope. I wouldn't want to read highly polished text then unpolished text.
15:35:03 [Ian]
CL: I would like it to be clear that the scope is limited.
15:35:41 [Ian]
TB: I think that a placeholder section would have tutorial value, just to point out to reader that they don't have everything they need in this doc.
15:35:49 [Ian]
NW: What about moving 5 to a finding?
15:37:19 [Ian]
CL: Proposal - leave section 5 in place (arch issues about m-to-m interaction) [2] move 5.2 to 5.2 [3] move 5.3 to 5.2 and list open issues.
15:37:37 [Ian]
TBL: Sounds to me like scope of section 5 is (1) working of http and (2) web services
15:37:46 [Ian]
(Arch principles behind them)
15:38:22 [Ian]
TBL: (a) Web Services arch and (b) Message passing that supports REST model
15:38:34 [Ian]
TBL: Design (a) of HTTP and (b) use of HTTP POST
15:38:57 [Chris]
if 5 is called interaction then we need 5.1 machine-machine interaction (ws, etc) and 5.2 human-machine interaction
15:39:32 [Ian]
RF: 5 is about communication between two separable components of the architecture.
15:39:40 [DanC]
q+ timbray
15:39:42 [Stuart]
q+ tbray
15:39:53 [Ian]
q- tbray
15:39:57 [Ian]
15:40:16 [Ian]
TB: I like the architectural tripod.
15:40:35 [Ian]
TB: I disagree with TBL - I think that interaction is qualitatively different and can be discussed separately.
15:40:54 [Ian]
TB: HTTP and Web Services models of interaction are what we would discuss here.
15:41:11 [Ian]
TBL: Interaction between client/server is done to create an information space view (quasi-static) to the user.
15:41:28 [Ian]
TBL: That illusion (reality!) is created by a bunch of http messages running back and forth.
15:41:43 [Ian]
TBL: We can talk about that, and we can talk about Web services
15:41:55 [Ian]
RF, CL: I would also add to that section - human/machine interaction (e.g., voice)
15:42:31 [Ian]
TB: I think that Human/Computer Interaction doesn't belong in section 5. I"m having a hard time thinking how hci issues fit into web architecture.
15:42:46 [Ian]
TB: I think the web arch should impose zero constraints on interaction from people.
15:42:47 [Roy]
15:43:01 [Ian]
CL: I disagree with TB on this point.
15:43:05 [Stuart]
ack timbl
15:43:31 [timbl]
HCI and WS are different.
15:43:40 [Ian]
TB: I propose we create a new top-level section on Human/Computer Interaction
15:43:51 [DanC]
eek! new sections now? hmm... i thought we were trying to figure out which parts we could finish this summer.
15:44:03 [Ian]
RF: The reason that HCI is part of this is *latency*.
15:44:12 [Chris]
good point
15:44:16 [Ian]
RF: Latency is important because of HCI part. It's part of the notion of the arch of the system.
15:44:23 [timbl]
We are trying to figure out ho wto describe the scope of what he have done -- this involves enummerating things out of the current scope.
15:44:58 [timbl]
15:45:10 [Stuart]
15:45:17 [Roy]
ack Roy
15:45:21 [Ian]
IJ: can we scatter HCI issues as rationale throughout the doc?
15:45:36 [Chris]
latency example - server-side imagemaps vs client-side imagemaps
15:45:40 [Ian]
TB: That makes sense; another example is transcribable URIs, or composability for formats.
15:45:50 [Ian]
TB: Maybe not a top-level section, but scattered throughout.
15:46:07 [Chris]
another latency example - 'getting a new html doc on every interaction' vs 'rollovers'
15:46:12 [Ian]
SW: Someone should take a close look at 5 and suggest an outline has TB has done for 4.
15:46:22 [timbl]
"y reducing the average latency of a series of interactions " - RF ch 5
15:46:40 [timbl]
15:46:49 [timbl]
Tim: Propose we sjip section5 fornow
15:46:55 [timbl]
that was timBray
15:47:27 [Chris]
so we go to last call with a bipod - an architecture for a static, non-interactive web
15:47:32 [timbl]
DanC: Propose we remove section 5 for practicality.
15:48:36 [timbl]
STRAW poll
15:48:43 [timbl]
Stuart: section syaing work to be done
15:48:45 [timbl]
Norm: too
15:48:51 [timbl]
TBRary too
15:48:57 [timbl]
TimBL: abstain
15:49:09 [timbl]
DanC: Remove entirely
15:49:19 [timbl]
Chris: section saying work to be done
15:49:25 [timbl]
Roy: " " " "" "
15:49:33 [timbl]
DO: wrok to be done.
15:49:52 [timbl]
(Ian off teh call)
15:50:30 [Chris]
15:50:44 [timbl]
6:1 in favor of putting it in as a placeholder explaining what work needs to bedone.
15:50:46 [Roy]
I will take action item to fill-out section 5
15:51:03 [timbl]
HCI, HTTP internals and WS
15:51:11 [timbl]
must be convreed somewher in that lot.
15:51:14 [timbl]
-- timbl
15:51:28 [Roy]
within two weeks
15:51:40 [timbl]
Roy: I volunteer to write the placeholder section
15:52:33 [timbl]
Roy will be unavailable for TAG class Aug 30.
15:52:44 [DanC]
Zakim, remind us in 15 minutes to resume from break
15:52:44 [Zakim]
ok, DanC
15:52:57 [DanC]
Zakim, room for 10?
15:52:57 [Zakim]
sorry, DanC, not enough capacity right now to add a 10 person conference
15:53:22 [timbl]
Interetsing to see whether the Zakim really is full or overvooked.
15:53:26 [timbl]
15:56:13 [DanC]
only 12 ports in use, per 15:55Z
16:03:30 [Ian]
Zakim is available since PPWG not meeting
16:07:44 [Zakim]
DanC, you asked to be reminded at this time to resume from break
16:09:40 [Roy]
nobody here
16:09:53 [DanC]
16:10:03 [Roy]
the new number
16:10:05 [DanC]
I'm on 617-258-7910
16:10:11 [Ian]
Please let's move to zakmi
16:10:13 [Ian]
16:10:24 [Ian]
code 0TAG
16:10:25 [Chris]
zakim, dial chris-work
16:10:25 [Zakim]
sorry, Chris, I don't know what conference this is
16:10:32 [Ian]
zakim, this is TAG
16:10:32 [Zakim]
sorry, Ian, I do not see a conference named 'TAG'
16:10:35 [Chris]
zakim, list
16:10:35 [Zakim]
I see WS_TF()12:00PM active
16:10:36 [Zakim]
also scheduled at this time are PP_PPWG()11:30AM, XML_XSLWG()12:00PM, XML_QueryWG()12:00PM, TAG_()10:00AM, QA_QAWG()11:00AM
16:10:40 [Roy]
no your not ;-)
16:10:42 [Ian]
zakim, this is TF
16:10:43 [Zakim]
ok, Ian
16:10:49 [Stuart]
Just dailing in
16:10:50 [Ian]
zakim, this is TAG_()
16:10:50 [Zakim]
sorry, Ian, I do not see a conference named 'TAG_()'
16:10:52 [Zakim]
WS_TF()12:00PM has been moved to #ws-desc by Philippe
16:10:53 [Chris]
zakim, dial chris-work
16:10:53 [Zakim]
sorry, Chris, I don't know what conference this is
16:10:58 [Ian]
zakim, this is not TF
16:10:58 [Zakim]
sorry, Ian, I do not see a conference named 'not TF'
16:11:06 [Ian]
zakim, this is TAG
16:11:06 [Zakim]
sorry, Ian, I do not see a conference named 'TAG'
16:11:13 [Ian]
zakim, this is 0TAG
16:11:13 [Zakim]
sorry, Ian, I do not see a conference named '0TAG'
16:11:23 [Norm]
zakim, this is tag
16:11:23 [Zakim]
ok, Norm
16:11:23 [Chris]
zakim, this is tag_
16:11:24 [Zakim]
Chris, this was already TAG_()10:00AM
16:11:25 [Zakim]
ok, Chris
16:11:25 [Zakim]
16:11:29 [Chris]
zakim, dial chris-work
16:11:29 [Zakim]
ok, Chris; the call is being made
16:11:30 [Zakim]
16:11:34 [Chris]
16:11:40 [Norm]
zakim, ??P3 is Roy
16:11:40 [Zakim]
+Roy; got it
16:11:43 [Ralph]
Ralph has joined #tagmem
16:11:45 [Norm]
zakim, who's on the phone?
16:11:45 [Zakim]
On the phone I see Norm, Roy, Chris
16:11:52 [Ian]
Hi Ralph, zakim seems to be happy now.
16:11:57 [Ian]
zakim, what conference is this?
16:11:57 [Zakim]
this is TAG_()10:00AM conference code 0824
16:12:05 [Ian]
zakim, call Ian-BOS
16:12:05 [Zakim]
ok, Ian; the call is being made
16:12:06 [Zakim]
16:12:13 [Ralph]
Ralph has left #tagmem
16:12:15 [Ian]
there is echo
16:12:37 [Zakim]
16:12:48 [Ian]
zakim, drop Ian
16:12:48 [Zakim]
Ian is being disconnected
16:12:48 [Zakim]
16:12:51 [Zakim]
16:12:59 [Ian]
zakim, call Ian-BOS
16:12:59 [Zakim]
ok, Ian; the call is being made
16:13:00 [Zakim]
16:13:04 [Ian]
zakim, drop Ian
16:13:04 [Zakim]
Ian is being disconnected
16:13:04 [Zakim]
16:13:07 [Ian]
zakim, call Ian-BOS
16:13:07 [Zakim]
ok, Ian; the call is being made
16:13:08 [Zakim]
16:13:14 [Chris]
zakim, drop chris
16:13:14 [Zakim]
Chris is being disconnected
16:13:15 [Zakim]
16:13:48 [Zakim]
+ +1.703.502.aaaa
16:13:57 [Chris]
zakim, passcode?
16:13:57 [Zakim]
the conference code is 0824, Chris
16:14:07 [Chris]
too late
16:14:19 [Zakim]
16:14:30 [Zakim]
16:14:40 [Stuart]
zakim, ??P4 is me
16:14:40 [Zakim]
+Stuart; got it
16:14:50 [Ian]
zakim, ??P6 is TimBray
16:14:50 [Zakim]
+TimBray; got it
16:14:54 [Ian]
zakim, who's here?
16:14:54 [Zakim]
On the phone I see Roy, Ian, Norm, +1.703.502.aaaa, Stuart, TimBray
16:14:55 [Zakim]
On IRC I see timbl, Roy, DanC, RRSAgent, Stuart, Norm, Zakim, Chris, Ian
16:15:44 [Zakim]
16:15:55 [Ian]
16:16:02 [Ian]
Walkthrough of arch doc
16:16:28 [Ian]
16:16:31 [Ian]
[Section 1]
16:17:42 [Ian]
[On section 6]
16:17:46 [Ian]
IJ: Move these to better home.
16:18:36 [Ian]
IJ: This was meant to be factoring out.
16:18:45 [Ian]
RF: I think ok to repeat in each section.
16:19:20 [DanC]
yes, let's nix section 6.
16:19:36 [Ian]
Proposed: Nix 6.1.
16:19:47 [Ian]
[RF may or may not reuse this text]
16:19:52 [Ian]
Resolved: Nix 6.1
16:19:58 [Ian]
Resolved: Nix 6
16:20:28 [Ian]
16:20:29 [Ian]
16:20:52 [Ian]
DC: "When followed" unclear to me.
16:21:10 [Chris]
sdection 1: Interaction. Agents exchange representations via a non-exclusive set of protocols, including HTTP, FTP, and SMTP1
16:21:16 [Ian]
TB: See my comments on adding "efficient..."
16:21:17 [Chris]
is not actualy adressed
16:21:40 [Ian]
DC: I think it means to say "When Web Arch is followed...."
16:22:18 [Ian]
RF: I wouldn't say that I'm happy with the abstract.
16:22:32 [Ian]
NW: Sounds like DC's comment is editorial.
16:22:45 [Ian]
DC: I'll try to wordsmith offline.
16:22:56 [Ian]
DC: I think it's worth giving the tripod a few words in the abstract.
16:23:54 [Ian]
RF: The abstract should say "we organized" not that "we did it"
16:24:25 [Ian]
RF: I read the abstract and it seems wrong; I don't have a better counter-proposal right now.
16:24:50 [Ian]
TB: Tripod is mentioned in abstract....
16:25:19 [Ian]
DC: I don't like "this document". Web architecture has three parts.
16:25:30 [Ian]
16:25:33 [Ian]
16:26:07 [Ian]
TB: Update to say 1-4 in decent shape; 5 absent
16:26:22 [Ian]
SW: Also, section numbering is all wrong.
16:26:36 [DanC]
pls don't refer by section # alone.
16:27:05 [Ian]
16:27:10 [Ian]
16:27:15 [Ian]
IJ: Ok highlighting principles there ok?
16:27:16 [Ian]
TB: Yes.
16:27:18 [Ian]
DC: Don't know.
16:27:20 [Ian]
SW: Fine for now.
16:28:01 [Ian]
DC: Lost a lot - sentence disappeared.
16:28:04 [Ian]
RF: I prefer that approach.
16:28:15 [Ian]
RF: I prefer that over shortening the essence.
16:28:30 [Ian]
DC: So I'm not happy with it but don't have a replacement.
16:29:11 [Ian]
NW: I may comment on TOC at later date.
16:29:18 [Ian]
16:29:24 [Ian]
1.1 Scenarios.
16:29:33 [Ian]
NW: I think that frag id discussion too confusing this soon.
16:29:41 [Ian]
NW: What about losing it from the scenario?
16:29:49 [timbl]
Zakim, who is here?
16:29:49 [Zakim]
On the phone I see Roy, Ian, Norm, +1.703.502.aaaa, Stuart, TimBray, DanC
16:29:51 [Zakim]
On IRC I see timbl, Roy, DanC, RRSAgent, Stuart, Norm, Zakim, Chris, Ian
16:30:14 [Zakim]
16:30:26 [Ian]
TB: Agree to lose the frag id part.
16:30:52 [Ian]
RF: Because it's a scenario, just say "found the URI in a travel magazine." I like the fact that he has to transcribe the URI.
16:31:27 [Ian]
Proposed: Lost frag id from 1.1 scenario.
16:32:06 [Ian]
IJ: I propose picking up the scenario with frag id part in section on frag ids.
16:32:25 [Ian]
16:32:32 [Ian]
- Lost frag id from scenario in 1.1
16:32:42 [Ian]
- Dan finds URI in a printed magazine
16:33:00 [Ian]
- IJ to try to move frag id part of scenario to section on frag ids (picking up thread from intro)
16:33:08 [Ian]
Resolved: adopt these proposals.
16:33:31 [Ian]
NW: Propose TAG ftf meeting in Oaxaca.
16:34:54 [Stuart]
16:35:10 [Ian]
IJ: Running with idea, continue scenario, e.g., in section on deep linking (e.g., DanC has to subscribe to magazine to get info)
16:35:22 [Ian]
RF: Highlight when you are talking about the scenario.
16:35:47 [Ian]
DC: I have heard TBL and RF say that have issues with terminology.
16:35:54 [Ian]
(e.g., "resource")
16:35:59 [Ian]
DC: Is the current 1.1 ok?
16:36:02 [Ian]
RF: Seems fine to me.
16:36:36 [Ian]
DC: Fix inconsistency between <b>agents</b> and "resources".
16:36:39 [Ian]
TB: Lose the bold.
16:37:06 [Chris]
16:37:06 [Ian]
TBL: I don't think that the text in 1 is affected by the TBL/RF issues.
16:37:17 [Ian]
TB: Use <b> consistently.
16:37:23 [timbl]
use <defn>
16:37:37 [Ian]
DC: It's useful for me to have distinctive markup for term definitions.
16:38:10 [DanC]
... and have the glossary point to them
16:38:26 [Ian]
IJ: Spec source in xhtml for now.
16:38:43 [Ian]
TB, DC: Highlight first instance of terms.
16:38:51 [Ian]
(And be consistent)
16:39:03 [Chris]
16:39:07 [Ian]
TB: Hyperlink back to first instances.
16:39:37 [Chris]
over-linked spec problem
16:39:52 [DanC]
I don't need all uses of a term marked up
16:41:14 [timbl]
Bets practice: When chosing a data format, it is best to chose one which is defined by a spec designed in the light of an architecture document which has been publiched using a namespace which supports multiple link destinations.
16:41:17 [timbl]
16:41:24 [Ian]
16:41:27 [Ian]
Section 2
16:42:19 [Ian]
16:42:23 [Ian]
TB: Drop "Some of the principles, practice, etc. may conflict with current practice, and so education and outreach will be required to improve on that practice. "
16:43:13 [Ian]
NW: Could be 1.2
16:43:19 [Ian]
DC: Prefer under section 1
16:43:38 [Ian]
TB, IJ: Don't feel strongly.
16:43:55 [Ian]
TB, DC: Keep scenarios up front.
16:43:55 [Norm]
NW: concerned that the scenario device may become too chatty for a normative spec
16:44:05 [Ian]
TB: I'd moderately prefer to keep a top-level section.
16:44:11 [Chris]
prefer 1.x, don't care over much
16:44:43 [Ian]
Remain top-level section: TB, IJ both mildly
16:44:47 [timbl]
16:44:50 [Chris]
i think we have more important things to worry about
16:45:06 [Ian]
Subordinate: SW, NW,
16:45:15 [Ian]
Go with majority: CL, TB
16:45:17 [DanC]
16:45:20 [Roy]
16:45:22 [Stuart]
16:45:37 [timbl]
The subordinates have it
16:45:39 [Ian]
Resolved: subordinate 2. under 1, after 1.1
16:45:42 [timbl]
16:46:00 [Chris]
add WSA
16:46:05 [Ian]
Resolved: Add WSA to list of arch specs in 2.2
16:46:43 [Ian]
TB: Furthermore, do we need the bulleted list at all? There will be other architectural things that bubble to the surface. This document is likely to be long-lived.
16:47:12 [Ian]
DC: I'd prefer to have citations to the actual specs : See charmod and the I18N Activity.
16:47:13 [timbl]
q+ pointers to specs works for me'
16:47:40 [Ian]
TBL: Create a references section and link down to that.
16:47:43 [Stuart]
16:47:45 [Ian]
16:47:48 [Ian]
- Mention Web services
16:47:55 [Ian]
- Link to references section in bottom of doc.
16:48:03 [timbl]
Other specifications in eth area of acc'y, di, and i18n apply [13-19].
16:48:06 [Ian]
[Consensus around that]
16:48:39 [Ian]
16:48:47 [Ian]
3. Identification and resources
16:49:20 [Ian]
RF: Having just rewritten intro to URI spec; need to sure that section 3. consistent with it.
16:49:23 [DanC]
I started reviewing RFC2396bis; my main comment at this point is: wow! lots of work went into the revision!
16:49:26 [Ian]
IJ: I read RFC; like it.
16:49:50 [Zakim]
16:49:52 [Ian]
RF: I've had positive comments only on the definitions of URIs, resources.
16:49:55 [Chris]
q+ to talk about opacity
16:50:07 [DanC]
ack danc
16:50:08 [Zakim]
DanC, you wanted to confirm terminology in section 1 and to ask about losing bold
16:50:28 [Ian]
16:50:37 [timbl]
rev 2002? ok
16:50:45 [Ian]
RF: I propose that we refer to the new document (rev-2002)...
16:51:10 [Ian]
Proposed: Refer to new URI spec (draft).
16:51:19 [Ian]
TB, NW, RF, IJ: Ok to point to this draft.
16:51:51 [Chris]
16:52:16 [Ian]
TB: Yes, I think it's ok to point to an internet draft on this one. Tell people it's a draft in progress.
16:52:31 [Ian]
CL: Ok, I'm happy to point to existing RFC2396 and say that it's being revised.
16:52:45 [Ian]
CL: Point to both.
16:52:47 [Ian]
16:53:08 [Roy]
16:53:08 [Ian]
TBL: We can call out an Internet Draft, even if it's not a standard.
16:53:51 [Ian]
TB: People are far-better served by RFC2396bis.
16:54:22 [Ian]
16:54:35 [Ian]
16:55:30 [Ian]
16:55:52 [Roy]
Can we please just refer to it as [URI] inside spec, and use references to indicate which one.
16:56:01 [Ian]
TBL: Suggest referring to rfc2396bis and in references section, indicate that this is an update..
16:56:24 [Ian]
16:56:30 [Ian]
ack Chris
16:56:30 [Zakim]
Chris, you wanted to talk about opacity
16:56:31 [DaveO]
DaveO has joined #tagmem
16:56:33 [DanC]
16:56:37 [Roy]
16:56:50 [timbl]
I suggested that we point to the one whose concepts and vocabulary we use in our doc.
16:57:42 [timbl]
note the currently endorsed standard has a number of differences and we refer to and uyse th terminolgy of th ebis draft indicated.
16:57:43 [Ian]
IJ: I second referring to [URI] and telling the story in the refs section.
16:57:51 [Roy]
ack Ian
16:57:52 [Chris]
I am happy to point to it, and to say why; I object to saying that it superceeds the RFC because it does not
16:58:02 [DaveO]
16:58:04 [Ian]
IJ: Seems ok to have docs and their refs evolve in tandem, even if drafts now.
16:58:07 [Chris]
the maturity axis and the we-like-it axis are orthogonal
16:58:09 [Ian]
ack Roy
16:58:13 [Ian]
ack DaveO
16:58:31 [Chris]
q+ to talk about opacity
16:58:58 [Ian]
DO: When do specs start referring to draft specifications. What is relation with, e.g., IRI spec references from other W3C docs?
16:59:25 [Ian]
RF: As an IETF writer, as long as we are not defining a technology standard (that would depend on others), we can refer to whatever we want.
16:59:45 [Ian]
DO: If Arch Doc refers to 2396bis, won't others do so as well?
16:59:59 [Ian]
DO: I agree that there is a diff between arch doc and a protocol/format spec.
17:00:00 [Chris]
ok so we can say that we should refer to IRI on the same basic, because its better ....
17:00:12 [DanC]
i thought I heard consensus: PROPOSED: "defined by [URI]" where [URI] points to and explains its relationship to RFC2396
17:00:18 [Ian]
RF: We do set precedent in some senses, but we shouldn't refer to JUST RFC2396.
17:00:25 [timbl]
q+ re sequnec fo RFCs
17:00:26 [Ian]
RF: The technology is defined by a sequence of specifications.
17:00:35 [timbl]
q+ to re sequnec fo RFCs
17:00:58 [Ian]
RF: My suggestion is to say in web arch that URIs are defined by "The URI specification". In Refs refer to both RFC2396 and the current effort to revise it.
17:01:18 [Ian]
17:01:25 [Ian]
ack Chris
17:01:25 [Zakim]
Chris, you wanted to talk about opacity
17:01:56 [Chris]
17:03:11 [Ian]
17:03:37 [Ian]
CL: Say in section 3 (w.r.t the scenario) that the URI COULD HAVE BEEN something else. Tie opacity into scenario.
17:04:51 [Ian]
ack timbl
17:04:51 [Zakim]
timbl, you wanted to re sequnec fo RFCs
17:05:01 [timbl]
17:05:16 [DanC]
we can move on
17:05:25 [Ian]
Resolved: "Create [URI] and deal with this in refs"
17:05:35 [Ian]
17:05:39 [Chris]
say could have been
17:05:40 [Ian]
- Tie in opacity to scenario
17:05:52 [Ian]
- Drop a reference to Stuart's finding.
17:05:54 [Chris]
or even, confusingly,
17:06:38 [Ian]
q+ TBray
17:06:41 [Chris]
q+ timbray
17:06:44 [Ian]
ack Ian
17:06:47 [Norm]
ack tbrya
17:06:49 [Norm]
ack tbray
17:06:52 [Norm]
ack timbray
17:07:22 [Ian]
TB: Delete "The term "resource" encompasses all those things that populate the Web: documents, services ("the weather forecast for Oaxaca"), people, organizations, physical objects, and concepts. "
17:07:39 [Ian]
TB: (from this paragraph)
17:08:43 [Ian]
IJ: I propose moving opacity to another para; keep first para about resources.
17:08:45 [Ian]
17:08:55 [Ian]
17:09:12 [Ian]
TB: Third paragraph - Delete technical usage note.
17:09:36 [Ian]
TB: Promote Editor's note to regular text.
17:09:56 [Ian]
TB: "TAG believes that internationization of URIs is architecturally important."
17:10:25 [Ian]
DC: "TAG considers". Say instead "IRIs are a valuable mechanism."
17:10:28 [Ian]
17:10:36 [Ian]
- IRIs are valuable work
17:10:41 [Ian]
- We think that are architecturally important.
17:10:57 [Ian]
RF: Create a "future directions" section for each leg of the tripod.
17:12:01 [Ian]
TB: "I18N of ids is's where the work'd being done."
17:12:09 [timbl]
Propose: s/which the TAG considers to be a valuable mechanism /which are proposed as a mevhamism/
17:12:22 [timbl]
Propose: s/which the TAG considers to be a valuable mechanism /which are proposed as a mechanism/
17:12:25 [Ian]
DC: What's valuable is the work on internationalization of ids.
17:13:11 [Ian]
Proposal: (1) Internationalization of URIs is architecturally important (2) We appreciate the work going on over here.
17:13:35 [Ian]
DC: I'd prefer saying "Future directions: IRIs are an open issue."
17:14:09 [timbl]
17:14:17 [Ian]
CL: On previous grounds, why can't we point to IRI draft?
17:14:27 [Ian]
RF: I think DC's objection is to "it IS a good mechanism"
17:14:36 [Ian]
DC: I note that we have NOT made a decision on IRIs.
17:14:40 [timbl]
q+ to ask whether we are discussing the IRI issue now or not.
17:14:53 [Ian]
17:15:12 [Ian]
DC: I'm not anywhere near closing IRIEverywhere-27
17:15:39 [Norm]
ack timbl
17:15:39 [Zakim]
timbl, you wanted to ask whether we are discussing the IRI issue now or not.
17:15:47 [Chris]
well, I am fairly close so please educate me
17:16:18 [Ian]
TBL: I've written down some pieces about IRIs and ties to other specs. Quite complex. I think that a number of people on the call are as yet unsure about the implications.
17:16:21 [DanC]
what is it that we've almost agreed to, chris?
17:17:05 [Ian]
Proposal: (1) TAG considers interationalization of URIs is architecturally important (2) We appreciate the work going on related to IRIs.
17:18:23 [Chris]
i like that proposal
17:18:35 [Ian]
TB: I think that several people are discovering that when you try to write down what we actually think, consensus is further off than we think.
17:19:05 [Ian]
IJ: TBL, how close are you to sending your proposal to www-tag?
17:19:31 [Ian]
TBL: Not sufficiently complete. The gist of the proposal involves defining the types of comparisons you want to do.
17:20:10 [Ian]
[More discussion of the proposal...presumably to illustrate to CL some of TBL or DC's issues]
17:20:25 [Ian]
17:20:46 [Ian]
TBL: TAG has not decided whether it wants to recommend that people use canonicalization.
17:22:41 [Ian]
Re-Proposal: (1) TAG considers interationalization of URIs is architecturally important (2) We appreciate the work going on related to IRIs.
17:23:57 [Ian]
DC: One of the most substantive discussion on IRIEverywhere occurred when I was not present. I didn't see "resolved" in minutes; so that's where I'm coming from.
17:24:03 [timbl]
(1) The tag recognises that the identitification relations implied by the URI and IRI specs are important and must be understood clearly before the architecture is defined in this area.
17:24:10 [Ian]
DC: Whatever we agree to on this issue, we need to be able to provide test cases.
17:24:18 [timbl]
^counter proposeal by timbl
17:24:41 [timbl]
17:24:54 [Ian]
ack timbl
17:25:11 [Ian]
[Still discussion details of IRI issues]
17:25:22 [Chris]
q+ to point out errors
17:25:37 [Ian]
TBL: There is an implication in IRI specs that people will do comparisons. This means [scribe thinks he heard] that some string comparisons won't work.
17:25:47 [Chris]
it explicitly says you cant convert back and expect to get what you started with
17:25:52 [DanC]
yes, I did some fact-checking about timbl's claims about the IRI spec, and I couldn't confirm.
17:26:08 [Ian]
TBL: The IRI spec says loudly that URIs and IRIs are both valuable (and both can appear in an href) . That blows up strcmp
17:26:20 [Ian]
17:26:27 [Chris]
it explicitly says to convert as late as possible and only to squeeze through hostile transports
17:27:21 [Chris]
straw poll please
17:27:32 [Ian]
Re-Proposal: (1) TAG considers interationalization of URIs is architecturally important (2) We appreciate the work going on related to IRIs.
17:27:39 [DanC]
"important" meaning: we accepted it as an issue.
17:27:52 [Ian]
IJ: We could jus tsay "we're following what's going on on IRIs"
17:28:05 [Ian]
Re-Proposal: (1) TAG considers interationalization of URIs to be architecturally important (2) We are following IRI work.
17:28:29 [Chris]
17:28:29 [Norm]
NW: Yes
17:28:48 [timbl]
tim: no
17:28:52 [Ian]
TB by proxy: Yes
17:28:56 [Stuart]
17:28:58 [DaveO]
do: yes
17:29:43 [Ian]
RF: My problem is "I18N of URIs" prefer "Localization of identifiers".
17:29:49 [Ian]
TB: I would prefer "I18N of identifiers"
17:30:14 [Ian]
RF: We are talking about localization here; they are only usable within a certain context.
17:30:45 [timbl]
no outcome.
17:30:49 [Chris]
localization is not the same as internationalzation
17:31:06 [Ian]
RF: I think we should have a section on future directions that talks about the IRI process and that's it.
17:31:29 [Ian]
CL: Why would we identify that as a future direction that we are interested in?
17:31:41 [Ian]
RF: We are interested in it; we need to find a solution to it. It's future work in the space of identifiers.
17:31:54 [Ian]
ack Chris
17:31:54 [Zakim]
Chris, you wanted to point out errors
17:32:45 [Ian]
DO: We haven't tackled, e.g., use of identifiers in Web Services.
17:32:55 [Ian]
DO: CL's point is "what's the problem we are trying to solve"
17:32:58 [Ian]
ack DanC
17:33:10 [Ian]
DC: The fact that we accepted the issue is evidence that we think this is important.
17:33:28 [Chris]
editor of what?
17:34:50 [Ian]
IJ: I would be comfortable saying "I18N of ids is important; TAG is following IRI work." Not sure if would be part of "future directions" section.
17:35:24 [Ian]
[Moving on]
17:35:59 [Ian]
NW: Throughout the document, we use widely varying domain names. Readers might think there is significance to the domain names. Let's pick on.
17:36:24 [Chris]
use consistently unless the domain name is actually significant
17:36:26 [Ian]
17:36:31 [Ian]
ack DanC
17:36:31 [Zakim]
DanC, you wanted to suggest weather.example
17:36:41 [Ian]
DC: Use weather.example
17:36:46 [Norm]
ack danc
17:36:49 [Norm]
ack ian
17:36:53 [Chris] or .com
17:37:07 [Ian]
1) Don't use real domains
17:37:17 [Ian]
TB: better than
17:37:27 [Ian]
TB: That looks weird to people.
17:37:40 [Ian]
17:37:52 [DanC]
".example" is recommended for use in documentation or as examples. --
17:38:06 [Ian]
17:38:16 [DaveO]
I support
17:38:16 [Norm]
ack ian
17:38:27 [Ian]
DC: I can live with
17:38:31 [Ian]
17:38:42 [Ian]
- Remove "real domain" names (not example.*)
17:38:45 [DanC]
e.g. yahoo
17:38:47 [DanC]
17:38:58 [Norm]
I actually propose "", not "example.*".
17:39:09 [Ian]
- Reduce overall number of sample domain names by hearkening back to scenario.
17:39:25 [Ian]
17:39:32 [Ian]
3.1. Comparing identifiers
17:39:40 [Ian]
TB: Take pointer to obsolete draft from para 4
17:40:32 [Ian]
TB: Section 6 of RFC2396bis improves on comparison text. I propose to strike 4th paragraph and say at end of first paragraph that discussed in [URI].
17:41:44 [Ian]
Delete "Issue..." at end of 3.1
17:42:55 [Ian]
IJ: DO talked to me about URIs in Budapest about, e.g., 1-1 relationship between URI/Resource.
17:43:33 [Ian]
DO: I liked our Irvine discussion.
17:43:42 [Ian]
DC: We have a hello world example in a scenario. We don't have a picture yet.
17:44:19 [Ian]
SW: I could do a draft of an illustration.
17:44:28 [Ian]
DC: Two world views on one-to-oneness...
17:44:30 [DaveO]
More than liked our irvine, found it useful though lots of it have faded from my memory, and my knowledge failed the test of trying to explain it.
17:44:43 [Ian]
RF: From discussion on URI mailing list, I'd be happy to just drop it.
17:44:52 [DanC]
3.1. Comparing identifiers
17:44:59 [DanC]
^that's what we're talking about, yes?
17:46:26 [Ian]
DO: I think that our discussion in Irvine should be captured here (two models)
17:47:12 [Ian]
DO: In the WSDL WG, they are looking at adding an attribute to services (proposed name "resource") to annotate a service description with a resource identifier for the thing that is behind the service.
17:47:28 [Ian]
DO: This would allow WSDL descriptions in multiple files but all related to the target resource.
17:47:30 [timbl]
17:47:50 [Ian]
DO: E.g., "David's printer". Web service A and Web service B (offered by company B) both relate to David's printer.
17:48:01 [Ian]
DO: The services are related because they both operate on David's printer.
17:48:44 [Ian]
17:48:57 [timbl]
17:50:24 [Ian]
TBL: Not sure to me that for a Web service generally, there is only one attribute (e.g., behind). I think this is an application level vocabularly.
17:51:39 [timbl]
I would describe issue 14 as a semantic web issue
17:51:39 [Ian]
[Seems to be about httpRange-14]
17:52:15 [Ian]
DO: This about httpRange-14, and fleshing out the two world views in the arch doc.
17:52:16 [Norm]
17:52:38 [Ian]
DC: I think that we can agree on the first picture, but that there are N views that conflict when you look at the details.
17:53:49 [Ian]
DO: Question we might want to answer - do two different URIs identify the same resource?
17:54:14 [Ian]
DO: i:identifiers, t:identifiers.
17:54:49 [Ian]
TBL: I think everyone agrees that you can have multiple ids for the same thing.
17:55:24 [Chris]
agree, lets carry on next monday
17:55:40 [Ian]
17:55:57 [Ian]
[Seems to be general agreement that today's discussion beneficial]
17:56:29 [timbl]
17:56:36 [Ian]
TB: I think that section 3 currently hits good 80/20 point. Not sure that we are missing some super important points before going forward.
17:56:42 [Ian]
DC: Consider my tree shaken. :)
17:56:45 [DanC]
80/20: 2nded.
17:56:48 [Ian]
17:56:57 [Ian]
17:57:05 [Ian]
17:57:11 [Ian]
Next session scheduled for 19 June.
17:57:20 [Ian]
SW: A number of people seem at risk on 19 June.
17:57:20 [Roy]
on plane 19 June
17:57:26 [Chris]
I am still ok for 19th
17:57:34 [Ian]
SW, RF, TB, DC at risk.
17:58:55 [Ian]
Proposed: 6 June.
17:59:03 [Ian]
TBL: I'm out of town 6 June.
17:59:13 [Ian]
Proposed: 9 June.
17:59:20 [Ian]
NW: Not sure I can arrange 4 hours.
17:59:26 [Ian]
TBL: 9 June is pentecost
18:00:11 [Chris]
proposal is 9:00-11:30 on monday?
18:00:17 [Ian]
Proposal: 3pm-5:30pm ET
18:00:31 [Roy]
18:00:36 [Ian]
Yes: TB, CL, SW, DC, NW, IJ, TBL, RF
18:00:41 [Ian]
Yes: DO
18:00:49 [Chris]
18:00:55 [Ian]
Resolved: Cancel 19 June, meet as proposed 9 June
18:01:34 [Ian]
18:02:22 [Ian]
Summarizing work for next week or so:
18:02:27 [Ian]
1) RF rewrite section 5
18:02:35 [Ian]
2) NW to rewrite section on hyperlinking
18:02:36 [Chris]
I will get Separation of semantic and presentational markup, to the extent possible, is architecturally sound
18:02:41 [Ian]
3) TB rewriting 4
18:02:44 [Chris]
ready for next wek
18:02:49 [Ian]
4) CL polishing up section on content/presentation
18:02:59 [DanC]
I'm working on HTML-in-RDF-nn
18:02:59 [Ian]
5) DO: Update issue 37
18:03:10 [Ian]
6) SW: Rewrites on opacity finding.
18:03:16 [Zakim]
18:03:18 [Ian]
7) IJ start working on rewrite of arch doc
18:03:23 [Ian]
18:03:25 [Zakim]
18:03:26 [Ian]
RRSAgent, stop