WS Arch WG Teleconference -- 6 Feb 2003

Present: Daniel Austin, David Booth, Doug Bunting, Tom Carroll, Alex Cheng, Roger Cutler, Paul Denning, Gerald Edgar, Martin Chapman, Hugo Haas, Dave Hollander, Yin-leng Husband, Mario Jeckle, Mark Jones, Heather Kreger, Sandeep Kumar, Frank McCabe, Don Mullen, Eric Newcomer, Srinivas Pandrangi, Waqar Sadiq, Igor Sedukhin Katia Sycara, Sinisa Zimek

Regrets: David Orchard, Abbie Barbir, Scott Vorthmann, Ugo Corda, Prasad Yendluri, Chris Ferris, Himagiri Mukkamala, Colleen Evans, Suresh Damodaran, Zulah Eckert, Shishir Garg, Duane Nickull

Chair: MikeC and DaveH

Scribe: dbooth

Profile input to XML and/or Schema WGs?

MikeC: I sent a msg to the TAG. TAG has done all it is going to do on it. They've left it as something the XML peopple should think about.
... Should we send the XML CG / XML Core WG this input as a requirement for their future work?

Daniel: I think it's a hornet's nest, but we should follow up with the groups that would perform the work.

MikeC: I'll draft something and send it to our admin list to see if we want to send it on.
... Should we also do something like this for the XML Schema WG?
... There's a sense that a profile of Schema might be useful.

DaveH: The note that we have talks about that profile. The Schema WG would love to see it and think about it.
... We could take a proposal back to have a discussion.

MikeC: So the whole Schema spec is too big for the average WS developer?
... So a smaller subset would help the practical developer community?

DaveH: At least let them react to the simplification proposals.
... E.g., people say that it's a schema problem that you need a DTD to get an entity in, but it's a core problem.

DaveH: Yes. It's up to us to be sure we've captured the needs. We should probably explore them with the WSDL group first.

Report on process questions for handling subgroups (Hugo, David B.)

Hugo: Sent email: http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Feb/0035.html
... People were discussing where to have discussion offline, and that brought up the charter requirement for public discussions.
... So we figured out how to address these concerns while following the process.

Hugo: Archiving doesn't cost a lot. It may be difficult to know when your in the midst of a conversation whether it will be important.

MikeC: To the extent we can do it without costing a lot or having to think to hard, we should err on the side of archiving.

Eric: Is the process saying that work goes on in the WG or TF but nowhere else?
... We had a breakout group that did a little work. Should it have been formulated as a TF?

Hugo: It is possible to use the public list and use subject tags for the TF archiving goal.
... But some are concerned that some ideas may generate a lot of traffic that may slow down the TF.
... So another option is to have TF mailing lists that would be publicly archived.
... If a separate TF mailing list isn't enough, then we could even restrict the posting rights to the members of the WG.

Katya: If Eric and I exchange messages outside, but we archive it somewhere, that is separate from who has posting and viewing rights.

Daniel: We could have different mailing lists, but it would still have to be publicly readable.

Hugo: There's a difference between an action item and a TF.
... Your breakout group was a particular case.
... People working for half hour is something else.

Kayta: We are creating something that is premature, and once something has solidified it's more difficult to. . .

MarkJ: I'm running a TF now (in another WG).
... We've been clearly marking in the subject line the acronym in the TF, and if people want to select them or delete them they can.
... It's been working well.

Hugo: The reason dbooth and I took this action item was to reduce the process discussions.
... We've been trying to summarize and propose that archiving is useful, not difficult, and if you're concerned about generating too much traffic, then we can create a separate list for the TF, which would still be publicly archived.

MikeC: What convention should we use?
... If it is too much using a convention then we can set up the TF list.
... For whatever reason, if we don't want a TF discussion to be on the main list, we can set up a public TF list.

dbooth: Regarding the gray area, yes there is one. use best judgement. ask yourself: would anyone else ever want to know what we are discussing?

dbooth: If Word or other proprietary document formats are sent, you should at least send an HTML version also.
... I have a perl script for this, but others are also available: http://dev.w3.org/cvsweb/~checkout~/2002/cleanwordhtml/

Glossary

Hugo: Some people sent back new glossary definitions. (Maybe only dbooth)
... We have the glossary in separate categories, but we're not sure if we should keep it this way, or what categories we should use.
... Roger went through the whole list of terms and compared with ebXML terms, and noted terms missing.
... Changes have been proposed in the public mailing list.

Roger: I made a working doc that merged a lot of terms together. It scared some people, because they thought it was tried to create a merged vocabulary between the two organizations.
... But we aren't.
... We're just trying to take what we find useful, and perhaps make a few suggestions to them.
... Duane suggest that we harmonize them, but I think that would be too much work.

Hugo: So that's where the document is. The proposed changes are in the list, and people can comment on them.
... Maybe we need to work on the categories.
... With the new re-org of the Arch document, it starts to read like a glossary, so we might need to merge or reconcile them better.

Roger: We've had a detailed discussion of these glossary terms on the list, and it hasn't generated perma-thread discussions.
... I'm much more comfortable now with them.

MikeC: All should look at the editor's draft to see if they're comfortable with the way they look.

Scribe: ACTION: Hugo to include the ebXML stuff that we propose to change, and post to list

Requirements document issues resolution (Daniel)

Daniel: There were a lot of issues, so I came up with a template to respond to all of them.
... Each email provides a summary of the issue, link, and proposed email to send to the original person who raised the issue.

Scribe: In general, the answers I proposed for each issue I thought were reasonable. In most cases I thought the commenter's comment was reasonable and that we'd make the change.

Daniel: The commenter's suggetion would require rewriting the whole requirements doc.
... So I came up with two proposed responses.
... Both are essentially saying "thanks, but we don't want to deal with this right now".
... In the editor's call yesterday, we thought #1 was superior.

Roger: Does #1 imply that the issue that he raises will actually be discussed and addressed?

Daniel: It's worded to be ambiguous.
... I didn't want to tell this person who spent 10 hours on their input to "drop dead". I think there is substantive meat to this person's comments.
... I'm just trying to get it out of the requirements doc, because i don't think it belongs there.

Roger: I think the comment boils down to rewriting the requirements doc to conform to his style.
... But i think he also had an important substantive comment.
... The concept of "context".
... Can we somehow extract the meat of this?

DaveH: When people send a shotgun message, you can break it into multiple issues.
... I think you could close it with option 1, but also raise a new issue regarding the "context" part.

Scribe: AGREED: We will follow DaveH's suggestion to close it with Daniel's proposed option 1, but also raise a new issue regarding the "context" suggestion.
... ACTION: Daniel to close 23 per his option 1, and open a new issue for "context"

Daniel: We need to resolve these proposed resolutions by next week if we're going to republish by the next F2F.

WSA document reorganization (Eric)

MikeC: We discussed the idea of refactoring the Arch draft. Eric took an action to try it.
... We want to see if this is a productive direction.

Eric: We discussed a new section called the "contract", which is a context-setting few paragraphs.
... We also tried to reorg the core concepts into a more formal structure.
... This was sent out for all to review.
... We also drafted something called the "stakeholder view".
... If we think of the core concepts of the arch as being the bricks, then the things in the stakeholder view would be the next level.
... E.g., the security view, or the management.
... There is draft text for each of those.
... I looked for text from the current document and put them where I thought they might go, to get a feel for how the doc might look under this new structure.

Eric: I also added a few paragraphs at the top describing the arch as an instance of a Service Oriented Arch.
... This helped me to decided what to include.
... I thought that would allow us to describe things more abstractly.
... So i thought i would give it a try.
... There's commentary on some things in the text, but i didn't change the text significantly, because i wanted to try this new format first.
... But I included comments as they occurred to me.
... I also put out the changes as a separate doc.
... And I sent a diagram of Service Oriented Arch (SOA).

Frank: Eric got some pushback on one idea: Not everything is a service.
... But it's confusing to say that, e.g., security is a service.

Eric: I tried to explain that, because I think modeling security as a service is a valid way to model it, though not all would choose to model it that way.
... It seems helpful to me to say there's a service for maintaining the context, do auth check, etc.

Frank: You have a sign on service, and an authentication service, and an encryption service, etc. Security itself is an over-arching concern.

Katya: I also gave pushback. At the F2F we discussed security and extensibility for example as measurable qualities.
... We could look at the degree of fulfillment of a particular "-ility".
... Even though some could think of them as services, in the document I think we should make more concrete distinctions.
... Because in essence, security is not just at the transport level, e.g.
... So I don't think we should push the service idea too far.
... Also in the previous document we used description and execution models interchangeably.
... We need to give some guidance, rather than just being a kitchen sink.

Daniel: I object to the idea of modeling security as a service. It's cross functional.
... The word "service" has too many meanings.

Daniel: We don't want the arch to suggest that these things have to be services.

Scribe: I think it's really good to try different ways of structuring the doc. I'm not sure we should keep it exactly like this, but i think it adds some new ideas.

MikeC: Perhaps a mix of the two ways of doing it would be good. Simple to complex, with points of greater precision mixed in.

Frank: We're writing a spec. There is a problem of getting the ear, the trunk etc of the elephant separately.
... One of the things a subsection can do is provide a "how to" approach to the arch.
... It could be simple-to-complex approach.
... As far as ordering the dictionary, the only ordering that makes sense in the text is alphabetical, because the concepts are a graph.
... In HTML you can click your way through it.
... But UML or other diagrams could be very helpful. I find UML very difficult to read, but diagrams can help.

Katya: Maybe now it reads as a dictionary. The thing that's important is the relationships.
... We need to relate every concept to every other concept.
... Most of the definitions, but no relationships.
... To me this is the main value.
... Also maybe bringing more text from the unstructured doc may help to avoid having it read too much like a dictionary.
... But having concepts and relationships explicitly, and then having examples, would be helpful.

Eric: I think the next step is to move some more text over, and have a look in a more complete form.

Roger: I think these people have done a great job. I am very uncomfortable with trying to push the SOA model too far.

Eric: That's loud and clear. We can work on that.
... The biggest concern was trying to model the "-ilities" as services.

Frank: And we need to bring in the requirements. We need to relate our requirements to the arch document.

Frank: What I did for scalability and extensibility, and looked at the top level goal and CSF in our requirements doc, and my section on that is a mirror.
... Look at the goals and see how much text we can use to fill in the mortar of the bricks.

Scribe: ACTION: Eric to incorporate these suggestions regarding the document draft
... [Meeting adjourned]

Pending Action Items

Scribe: From last week's IRC log: http://www.w3.org/2003/01/30-ws-arch-irc.txt
... PENDING ACTION: Chairs to do invite P3P group at Plenary
... PENDING ACTION: Daniel to do Glossary terms update from requirements documents
... PENDING ACTION: DaveH to do summarize bottom-up reliability notes
... PENDING ACTION: DaveO to do publish his critique of WS-Desc document
... PENDING ACTION: DavidBooth to do get self added as Editor
... PENDING ACTION: DonMullen DanC to do resolve issue 4
... PENDING ACTION: Frank Eric Katia Zuah to do refactoring of WSA document
... PENDING ACTION: Hugo to do Glossary - missing definitions from document in Glossary
... PENDING ACTION: Hugo to do add a priori to Glossary
... PENDING ACTION: Hugo to do contact WSD document editor and resolve this issue
... PENDING ACTION: Mike to do recruit members to work on Usage Scenarios Document as co-editor
... PENDING ACTION: wsa-members to do all note-takers from break outs to send notes to W3C-WS-ARCH list

WS Arch WG Teleconference
6 Feb 2003

Attendees

Contents