Re: The version element and workspaces

IEEE/WIC/ACM WI-IAT'06: Last Call for Workshop Proposals

[Apologies if you receive this more than once]

==============================================================
Call for Workshop Proposals

2006 IEEE/WIC/ACM International Joint
Conference on Web Intelligence and Intelligent Agent Technology
(WI-IAT'06)

Hong Kong Convention and Exhibition Centre, Hong Kong, China,
18-22 December 2006

http://www.comp.hkbu.edu.hk/~wii06

*******************************************************************
Workshop Proposals Due: 10 April 2006
All papers accepted for workshops will be included in the Workshop
Proceedings published by the IEEE Computer Society Press
===================================================================

The Program Committees of the 2006 IEEE/WIC/ACM International Joint
Conference on Web Intelligence and Intelligent Agent Technology
(WI-IAT'06) invite proposals for Workshops.  The Workshops will be
held at the beginning of the Conference, December 18, 2006 at Hong
Kong Convention and Exhibition Centre.

The workshop organizers will be responsible for advertising the
workshop, forming the program committees, reviewing and selecting the
papers, and guaranteeing a high quality worthy of the prestige and
range of the Conference.  All papers accepted for workshops will be
included in the Workshop Proceedings published by the IEEE Computer Society
Press and will be available at the workshops.

The workshop organizers will also have the discretion of editing
selected papers (after their expansion and revision) into books or
special journal issues.  Workshops may be full-day or half-day. A
full-day workshop should select 20-25 regular papers, while a half-day
workshop should select 10-13 regular papers, from a large number of
submissions.  The workshop organizers should ensure the presence of
authors of accepted papers at the workshops.

I. Workshop Topics

Each workshop subject will focus on new research challenges and
initiatives in Web Intelligence (WI) and Intelligent Agent Technology
(IAT).  The workshops should provide an informal and vibrant forum for
researchers and industry practitioners to share their research results
and practical development experiences in these two fields.  Suggested,
but not limited to, workshop topics include:

- Intelligent E-Technology (including E-Science, E-Business,
              E-Learning, E-Finance, E-Government, E-Community)
- Intelligent Human-Web Interaction
- Knowledge Grids and Grid Intelligence
- Semantics and Ontology Engineering
- Social Networks and Social Intelligence
- Ubiquitous Computing
- Web Agents
- Web Information Filtering and Retrieval
- Web Mining and Forming
- Web Security, Integrity, Privacy and Trust
- Web Services and Grid Services
- Web Support Systems
- World Wide Wisdom Web (W4)
- Agent Systems Modeling and Methodology
- Autonomous Knowledge and Information Agents
- Autonomous Auctions and Negotiation
- Autonomy-Oriented Computing (AOC)
- Learning and Self-Adapting Agents
- Distributed Intelligence

II. Workshop Proposal Submission

Workshop proposals should include the following elements:

- Title of the workshop
- Your name, affiliation, mailing address and e-mail address
- A description of the topic of the workshop (not exceeding 200 words)
- Type of the workshop (full-day or half-day)
- A description of how the workshop will contribute to the field of
  Web Intelligence and/or Intelligent Agent Technology
- A short description on how the workshop will be advertised so as
  to ensure a sufficiently wide range of authors and high quality papers

After the acceptation of a workshop proposal the organizer(s) should:

- Create a "Call for papers/participation" for the workshop
- Create a Web page for the workshop, the link of which will be published
  on the Conference Web site
- Create a Board of Reviewers (Program Committee)
- Review and select papers
- Schedule the workshop activities

Those papers selected by a workshop organizer will also be reviewed by
the Workshop Co-Chairs for final acceptance.

All submitted papers will be reviewed on the basis of technical
quality, relevance, significance, and clarity.

We will provide an online paper submission and review system
to support the workshops.

III. Important Dates

- April 10, 2006: Workshop proposal submission due
    (Please send proposals by e-mail to all three Workshop Co-Chairs)
- April 20, 2006: Notification to workshop proposers
- April 30, 2006: Each workshop organizer sends out Call for Workshops
Papers
- July 30, 2006: Due date for full workshop papers submission
                 (at least two reviews for each paper)
- September 5, 2006: Final acceptance by Workshop Co-Chairs
- September 8, 2006: Notification of paper acceptance to authors
- September 29, 2006: Camera-ready of accepted papers
- December 18, 2006: Workshop day

We look forward to your support in making 2006 IEEE/WIC/ACM WI-IAT
workshops an exciting event.

Workshop Co-Chairs:

Cory J. Butz, University of Regina, Canada
              E-mail: butz <at> cs.uregina.ca
Ngoc Thanh Nguyen, Wroclaw University of Technology, Poland
              E-mail: thanh <at> pwr.wroc.pl
Yasufumi Takama, Tokyo Metropolitan University, Japan
              E-mail: ytakama <at> cc.tmit.ac.jp

Note: we will not have a separate workshop registration fee this year
(i.e., only one conference registration covers everything).

For your information, the WI-IAT'06 conference will be co-located with
the IEEE International Conference on Data Mining (ICDM'06) for
providing synergism among the three research areas. It will provide
opportunities for technical collaboration beyond that of previous
conferences. The three conferences will have the joint opening,
keynote, reception, and banquet. Attendees only need to register one
conference and can attend sessions across the three conferences. We
are planning to have a joint panel and joint paper sessions that
discuss common problems in the three areas.

Re: The version element and workspaces

If new clients should work with older servers there should be
a mechanism for a client to detect the compliance level of the
server. It can then act accordingly. In RFC 2518 the DAV header
seems to be used for this. I don't find such a mechanism in
RFC 3253.

Regards,

Werner.

Geoffrey M Clemm wrote:
> 
> Any new addition to the specification will cause any client that uses
> that addition to fail against older servers that were implemented
> before that addition was defined.  To avoid this kind of failure,
> we do not introduce changes in revisions of the specification unless
> the benefit provided by that feature outweighs the cost of those failures.
> 
> Cheers,
> Geoff
> 
> Werner Donné <werner.donne <at> re.be> wrote on 03/31/2006 06:50:00 AM:
>> Geoffrey M Clemm wrote:
>> > One would need to identify a significant interoperability or performance
>> > problem in order for it to merit a revision to the specification.  
>> > I don't think either would apply to this extension.
>>
>> Neither interoperability nor performance have anything to do with it. The
>> proposed extension doesn't break anything and if using a label in this
>> context could present a performance problem, then it would too in the
>> contexts where it is used now. It is only a matter of consistency. When
>> the label feature is supported, labels can be used for version selection
>> when a VCR is given, only not in all situations, for which I see no
> reason.
>>
>> The use-case for workspaces is also very valid. When activities are
> supported
>> and used for branching, it is common to define the start of a new branch
>> based on a label instead of a physical version. Otherwise you can forget
>> about more advanced configuration management practices.
>>
>> Why would interoperability and performance problems be the only reason for
>> a revision? This implies that the current feature set should be considered
>> as perfect, because how did the current features make it into the
>> specification
>> then? How does the revision process work?
>>
>> Performance is a non-issue. There is nothing shocking in WedDAV that would
>> cause performance problems by definition and I don't see why additions
> would.
>> The implementation should be sofisticated enough or simply not implement a
>> feature.
>>
>> I agree that an extension shouldn't break interoperability, unless in a
>> major upgrade. Note, however, that this is not the same as requiring
>> that most existing implementations are able to implement it, because that
>> would mean the specification is not leading but merely consolidating an
>> existing state of affairs. WebDAV deserves to be more than window dressing
>> of existing products.
> 

--

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne <at> re.be

Re: The version element and workspaces

Werner Donné wrote:
> If new clients should work with older servers there should be
> a mechanism for a client to detect the compliance level of the
> server. It can then act accordingly. In RFC 2518 the DAV header
> seems to be used for this. I don't find such a mechanism in
> RFC 3253.

Well, the mechanism would be the same.

The major question here is whether there's a group of implementors who 
want that feature. In which case the right thing to do is to define an 
extension (including the aforementioned discovery mechanism), and 
publish it in an Internet Draft. If that gets traction, you may be able 
to get it published as RFC through either the RFC Editor or the IESG. 
If, at a future date, RFC3253 gets revised, the authors then will 
certainly consider extensions that have been published since for 
inclusion into the base protocol.

Sounds complicated? Yes. Consider it a way to prevent feature creep 

Best regards, Julian

Re: The version element and workspaces

checkin-set

Hi,

If activities and workspaces are used together to implement branches,
each branch could be checked out if there is a workspace, which has a
VCR, that is linked to the first version of that branch.

If I now want to do a check out in a branch I need to locate the
correct VCR. Since the branches are visible in the version tree, the
obvious point for a check-out is the last checked-in version on the
branch. However, a version can't be used as the request URL of the
CHECKOUT method.

How can I find the correct VCR given a version and knowing in which
workspace I want to do it? If a version had a checkin-set, analogous
to the checkout-set, all VCRs could be obtained that have the version
as the checked-in version. Then the workspace properties could be
retrieved for the resulting VCRs and the one with the right property
could be used for the check-out. Is there an alternative for this?

Regards,

Werner.
--

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne <at> re.be

Re: checkin-set

Re: checkin-set

>> each branch could be checked out if there is a workspace,
> 
> You don't checkout a branch/activity ... you checkout a VCR against a
> branch/activity.
> 
>> which has a VCR, that is linked to the first version of that branch.
> 
> Not sure what you mean by "linking the VCR to the first version of that
> branch".  The VCR is linked to a branch/activity by being checked-out
> against
> that branch/activity, which will set the DAV:activity-set of that VCR to
> reference
> that branch/activity.

I meant a workspace with a VCR that was created with the first version
of the branch/activity.

>  
>> If I now want to do a check out in a branch I need to locate the
>> correct VCR.
> 
> You locate the correct VCR by knowing the pathname of that VCR relative
> to the root of your workspace.  So if you want to checkout src/foo.c
> in workspace http://my.server/ws/myws, you would checkout
> http://my.server/ws/myws/src/foo.c.
> 
> You indicate what branch/activity you are working on by setting the
> DAV:current-activity of your workpspace to reference that branch/activity.

I think this is the clue. If the current activity of a workspace is
changed, can this affect the checked-in version of a VCR? Is the system
allowed to set it to the most recent version within the activity if
such a version exists?

> 
>> Since the branches are visible in the version tree,
> 
> A version has a DAV:activity-set property which indicates
> what branch/activity it is in.  Is that what you mean by "visible
> in the version tree"?

Yes.

> 
>> the
>> obvious point for a check-out is the last checked-in version on the
>> branch. However, a version can't be used as the request URL of the
>> CHECKOUT method.
> 
> You checkout whatever is the current checked-in version of the
> VCR with the appropriate pathname in your workspace.  If it is
> not selecting the last checked-in version (or a successor of the last
> checked-in version) in that branch/activity, then the CHECKOUT will fail
> because it violates the DAV:linear-activity pre-condition (unless you
> have set DAV:unreserved on the VCR, in which case you will be allowed
> to CHECKOUT, but the CHECKIN will fail, with a DAV:linear-activity
> precondition failure).
>  
>> How can I find the correct VCR given a version and knowing in which
>> workspace I want to do it?
> 
> The client has to specify the pathname of the VCR they want to checkout,
> from which the system can infer the workspace (the DAV:workspace property
> of the VCR).  If you want to checkout a particular version, then you
> UPDATE the VCR to be that version before you issue the CHECKOUT (remember,
> this is *your* workspace).
> 
>> If a version had a checkin-set, analogous to the checkout-set,
>> all VCRs could be obtained that have the version
>> as the checked-in version.
> 
> In a distributed implementation, you don't know all the workspaces
> that are currently looking at a particular version ... there could be
> thousands, on many servers (in a distributed system, the version
> history is often not on the same server as the workspace).
> So we don't require that a WebDAV server maintain this information.
> 
>> Then the workspace properties could be
>> retrieved for the resulting VCRs and the one with the right property
>> could be used for the check-out. Is there an alternative for this?
> 
> It makes no sense to checkout a VCR in some random workspace.  A workspace
> is owned by a particular individual (or perhaps team) that wants to see a
> consistent configuration (i.e. the configuration defined by the VCR's in
> that
> workspace).  When you checkout a VCR, you checkout the version of that VCR
> that is in that configuration, and if you want some other version to
> appear in
> that configuration, you perform an UPDATE to make that version appear in
> that
> workspace.

Do I understand it correctly then that if a user wants to check out on a
branch/activity within a version history he has to "import" the last version
in that activity by making sure there is a VCR in his workspace that has
its checked-in version set to it? Possibly the user has to create a VCR first
in his workspace using that version.

If that is true, and assuming collections are supported, the user has the
flexibility to create his own "directory tree" in his workspace with all the
items he is working on. On the other hand he always has to do this "import"
action and manage this "directory tree". Would it be allowed to generate
VCRs automatically when a workspace is created? For example, VCR /a/b/c would
lead to /ws/myws/a/b/c.

> 
> Cheers,
> Geoff

Regards,

Werner.
--

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne <at> re.be

Re: checkin-set

Re: checkin-set

Thank you very much.

Regards,

Werner.
--

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne <at> re.be