-
Notifications
You must be signed in to change notification settings - Fork 0
/
osr-101.xhtml
791 lines (683 loc) · 30.5 KB
/
osr-101.xhtml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<?xml-stylesheet type="text/xsl" href="xhtml.xsl"?>
<html>
<head>
<link rel="neutron-introspection" type="application/neutron+xml" href="introspection-osr-101.xml"/>
<title>OSR-101 - Neutron Specification</title>
</head>
<body>
<h1>Neutron - Remote Content Authoring API</h1>
<h2>Open Specification Request 101</h2>
<dt>Version: 0.0.1</dt>
<br/>
<dt>Revision Date: 17 August 2006</dt>
<br/>
<dt>Editors:</dt>
<dd>
Thomas Comiotto <a href="mailto:[email protected]?subject=OSR-101">[email protected]</a>
<br/>
Michael Wechner <a href="mailto:[email protected]?subject=OSR-101">[email protected]</a>
<br/>
Guido Wesdorp <a href="mailto:[email protected]?subject=OSR-101">[email protected]</a>
<br/>
Andreas Wuest <a href="mailto:[email protected]?subject=OSR-101">[email protected]</a>
</dd>
<hr/>
<h2>Table of contents</h2>
<ol>
<li>Introduction</li>
<li>Basic terms and concepts</li>
<li>Introspection</li>
<ol>
<li>Introspection Link</li>
<li>Introspection File</li>
<li>Navigational Information</li>
<li>Topic Maps</li>
</ol>
<li>Authentication / Authorization</li>
<li>Remote File Operations</li>
<ol>
<li>New</li>
<li>Open</li>
<li>Save</li>
<li>Save As</li>
<li>Exit</li>
<li>Close</li>
<li>Close All</li>
<li>Save All</li>
<li>Hypertext Link Lookup</li>
</ol>
<li>Editing</li>
<li>Search</li>
<li>Revisions</li>
<li>Scheduling</li>
</ol>
<hr/>
<a name="introduction"/>
<h2>Introduction</h2>
<p>
Neutron is an xml-based application level protocol for remote content authoring. Neutron provides a set of methods and configuration directives that allow for:
<ul>
<li>concurrent access to resources</li>
<li>basic file operations (move, delete)</li>
<li>creating resources based on templates</li>
<li>linking resources to datatype definitions</li>
<li>providing styling information for resources</li>
<li>metadata handling</li>
<li>accessing revisions</li>
<li>dealing with publishing workflow stages</li>
<li>custom authentication schemes</li>
<li>and more</li>
</ul>
</p>
<p>
Neutron has been been started as an effort to provide a generic API to what common Content Management Systems (CMS) support with respect to content authoring. CMS vendors usually implement their own frontend components for content authoring and/or implement a public API for third party component integration. Neutron is ment to be an open standard that leverages integration and reuse of third party components such as editing applications or standalone clients targeted at offline operation. While targeted at large scale content management systems, Neutron can also be used for accessing lightweight content repositories, datastores or remote file systems.
</p>
<p>
Neutron is typically used over HTTP. However, Neutron can be run on top of any other transport protocol if feasable.
</p>
<p>
Neutron provides a comprehensive set of instructions for dealing with xml-based resources. Usage of xml-based resources is not required though. Neutron also covers transactions of binary or custom formatted data while being extensible enough for integrators to deal with the data formats of their choice.
</p>
<p>
Compared to other open content authoring standards Neutron is higher-level than WebDAV and lower-level that ATOM, to name two prominent examples in that field. While WebDAV operates on Web resources Neutron operates on content servers that might expose their resources to the web. While ATOM is targeted at content syndication Neutron provides a generic API to content authoring.
</p>
<p>
For examples and usage patterns see Appendix I (Examples).
</p>
<h2>Basic terms and concepts</h2>
<h3>Neutron Methods</h3>
<p>
Neutron defines a set of methods and corresponding exception types for operating on remote resources:
<dl>
<dt>open</dt>
<dt>save</dt>
<dt>lock</dt>
<dt>unlock</dt>
<dt>checkout</dt><dd>Convenience Mehod for open + lock</dd>
<dt>checkin</dt><dd>convenience method for save + unlock</dd>
</dl>
These methods can be assigned to arbitrary commandURLs. If a content server must adhere to some url namespace policy, Neutron has been designed to be flexible enough to support it.
</p>
<h4>
Example - Saving a resource over HTTP using PUT</h4>
<p>
Method: save<br/>
CommandURL: http://foo.bar.com/foo.html?neutron.cmd=save<br/>
Neutron representation:
<![CDATA[
<save uri="http://foo.bar.com/foo.html?neutron.cmd=open" httpMethod="PUT"/>
]]>
<br/>
</p>
<h4>Example - Saving a resource over HTTP by using POST. Single service endpoint</h4>
<p>
Method: save<br/>
CommandURL: http://foo.bar.com/neutron?cmd=save&file=somefile<br/>
Neutron representation:
<![CDATA[
<save uri="http://foo.bar.com/neutron?cmd=save&file=somefile" httpMethod="POST"/>
]]>
<br/>
</p>
<h3>Initiating a Neutron request/response chain</h3>
A Neutron request/response chain is initiated by issuing a set of configuration directives that contain:
<ul>
<li>commandURLs for the methods supported by the content server</li>
<li>datatype definitions for the requested resource(s) - if available</li>
<li>hinting directives regarding the preferred editing mode of the resource (forms based, WYSIWYG), including data that is needed to render the corresponding client-side application components. </li>
</ul>
These configuration directives are contained in a Neutron Introspection File and provided by the content server.
<h4>Example - Introspection file</h4>
<pre><![CDATA[<introspection>
<edit mode="styled">
<open url="http://www.foo.bar.com/hello.xml"/>
<save url="http://www.foo.bar.com/hello.xml?neutron.cmd=save" httpMethod="PUT"/>
<style url="http://www.foo.bar.com/hello.xsl"/>
<schema url="http://www.foo.bar.com/hello.xsd"/>
</edit>
</introspection>]]></pre>
<p>
The term "introspection file" accounts for the fact that remote resources are usually not self-contained in terms of data that is needed to edit them. This not only conscerns remote methods to access the resource. Resources might also lack embedded links to relevant datatype definitions and to styling information needed to edit them in WYSIWYG-mode. Further on, most content servers process resources before making them available to end-users. For instance, Web-based content management systems usually add document headers, navigation menus, resolve include directives on the fly etc. before sending the processed resource out to page visitors. Given that processed resources are the reference point of choice for content authoring, they are also a good entry point for editing the underlying static resources in terms of user interaction. Neutron supports embedding a link within a processed resource that refers to an introspection file, therefore allowing for initialization of a Neutron request/response chain by introspecting a processed resource. The notion of such introspection links is as follows:
<pre><![CDATA[
<link rel="application/neutron+xml" href="urlToIntrospectionData.xml"/>
]]></pre>
</p>
<p>
Introspection links allow for browsing a website or document repository for instance, gathering information about how to edit the underlying data behind the scenes and let content authors initiate a neutron request/response chain on demand.
</p>
<p>
Note that using an introspection link that refers to an introspection file is only one way to initiate a Neutron request/response chain. Introspection files can also be provided as part of an Neutron archive (see below) or simply by letting users locate them directly from within a Neutron enabled client.
</p>
<h3>Linking resources to datatype definitions</h3>
<p>
Linking resources to datatype definitions is crucial for allowing clients to validate the resource during the authoring process or to provide for datatype-guided content insertion. With regards to XML-based resources, this information is often not self-contained but dealt with by the content server. Linking a resource to a datatype definition is achieved by adding a schema element to the introspection file. Neutron has support for three datatype languages: W3C Schema, RelaxNG and Schematron.
</p>
<h4>Example - Linking a resource to its datatype definition</h4>
<pre><![CDATA[
<edit>
<schema type="relaxNG" url="aRelaxNGFile.rng"/>
</edit>
]]></pre>
<h3>Edit modes and styling information</h3>
<p>
Neutron supports a set of directives targeted at client-side view configuration. While these directives are somewhat XML-biased they are extendable to support data formats of choice. As noted earlier, content servers usually process resources by adding dynamic document parts like menus and headers or by resolving inclusion directives for instance. Moreover, XML-based systems often use custom datatypes that are transformed to xhtml before being served to end-users. With regards to authoring, editing pre-processed static resources based on their mime-types (as supported by most other content authoring protocols out there) is fine as far as source mode editing is conscerned. However, when considering WYSIWYG-editing (which is what content authors usually prefer) additional information has to be provided to the client-side application:
<ul>
<li>directives about how to style the resource</li>
<li>document parts that result from server side processing (header, menus, footer, ..) with regards to WYSIWYG editing</li>
</ul>
Neutron has support for both aspects while keeping integration cost as low as possible by leveraging reuse of existing server side code. In terms of styling a resource two modes are supported: styling by CSS and styling by XSLT. To declare a stylesheet for a given resource a style element has to be added to the introspection file.
<h4>Example - Declaring a css style for a resource</h4>
<pre><![CDATA[
<edit>
<style type="css" url="aCSSfile.css"/>
</edit>
]]></pre>
<h4>Example - Declaring a xslt style for a resource</h4>
<pre><![CDATA[
<edit>
<style type="xslt" url="aXSLTFile.xsl"/>
</edit>]]>
</pre>
</p>
<p>
Document parts needed for WYSIWYG-editing but resulting form server side processing such as headers, menus, footers etc. are provided to the client-side application by declaring a view template. View templates contain xi:include directives for inclusion of editable resources. A view template typically consist of custom data surrounding xi:include directives that reference static and therfore editable resources. Styling directives given in the introspection file are ment to be applied to the view template (if present) after the xi:include directives contained have been resolved by the client side application.
</p>
<h4>Example - View Template</h4>
<pre><![CDATA[
<page>
<head>
<title>A document title</title>
</head>
<menu>
<item uri="index.html"/>
<item uri="hello.html" selected="selected"/>
</menu>
<content>
<xi:include href="hello.xml"/>
</content>
</page>
]]>
</pre>
<h4>Example - Declaring a View Template in a Introspection File</h4>
<pre><![CDATA[
<introspection>
<edit>
<open url="hello.xml"/>
<style mode="xslt" url="page.xsl">
<template url="hello-template.xml"/>
</style>
</edit>
</introspection>
]]>
</pre>
<p>
View templates can be shared between multiple resources. This is needed in situations where a processed resource consists of several otherwise unrelated resources - for instance a xml-based resource being transformed to a single html page after having aggregated a couple of rss-feeds. A view template is considered a shared template if the template directives of individual resources listed in the introspection file point to the same view template. Shared view templates need to include all relevant resources by providing xi:include directives for all those resources.
</p>
<h4>Example - shared View template</h4>
<pre><![CDATA[
<page>
<head>
<title>A document containinig a rss feed</title>
</head>
<menu>
<item uri="index.html"/>
<item uri="hello.html" selected="selected"/>
</menu>
<sidebar>
<xi:include href="feed.xml"/>
</sidebar>
<content>
<xi:include href="hello.xml"/>
</content>
</page>
]]>
</pre>
<h4>Example - sharing a View template</h4>
<pre><![CDATA[
<introspection>
<edit>
<open url="hello.xml"/>
<style mode="xslt" url="page.xsl">
<template url="hellotemplate.xml"/>
</style>
</edit>
<edit>
<open url="feed.xml"/>
<style>
<template url="hellotemplate.xml"/>
</style>
</edit>
</introspection>
]]>
</pre>
<h3>Resource Sets</h3>
<p>
Neutron supports synchronized transactions of multiple resources by adding them to a resource set. A method call on any member of a resource set leads to executing the same method on all other members of the resource set. A method call on any member of a resource set can only be considered successful if the same method can be executed successfully on any other member of the resource set and otherwise will be reverted. A typical usecase for a resource set is when dealing with metadata contained in a seperate resource. For instance, given a resource set that contains resource A and another resource B that holds metadata of A, Neutron enabled applications can make sure that document and metadata are opened, locked, saved, unlocked together.
</p>
<h4>Example - Resource set</h4>
<pre><![CDATA[
<introspection>
<resource-set>
<resource url="hello.xml">
<save url="hello.xml?neutron.cmd=save"/>
</resource>
<resource url="hello.meta">
<save url="hello.meta?neutron.cmd=save"/>
</resource>
</resource-set>
</introspection>
]]>
</pre>
<a name="introspection"/>
<h2>Introspection</h2>
<p>
The communication between the client and server can be initialized by
introspection. This also allows the server to tell the client of it's
capabilities (e.g. level 1, 2, 3 compliance). Also see the specification of <a href="http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt">Atom</a> resp. <a href="http://bitworking.org/projects/atom/">http://bitworking.org/projects/atom/</a>.
</p>
<p>
Finding the introspection file (auto-discovery)
</p>
<pre>
<![CDATA[
<?xml version="1.0"?>
<html>
<head>
<link rel="neutron-introspection" type="application/neutron+xml" href="introspection.xml"/>
</head>
</html>
]]>
</pre>
<p>
An example of an introspection file
</p>
<pre>
<![CDATA[
<?xml version="1.0"?>
<introspection xmlns="http://www.wyona.org/neutron/1.0">
<edit mime-type="application/xhtml+xml" name="Related Content">
<!-- Edit "Related Content" -->
<open url="http://foo.bar.com/test.xhtml" method="GET"/>
<!-- Checkout and Edit "Related Content" -->
<checkout url="http://foo.bar.com/test.xhtml?action=checkout" method="GET"/>
<!-- Save "Related Content" -->
<save url="http://foo.bar.com/test.xhtml?action=save" method="POST"/>
<!-- Save and Checkin "Related Content" -->
<checkin url="http://foo.bar.com/test.xhtml?action=checkin" method="POST"/>
</edit>
<edit mime-type="application/xml" version="433453" name="Main Content">
<open url="http://foo.bar.com/lenya/default/authoring/index.html?lenya.usecase=open" method="GET"/>
<!-- Also see authentication and authorization ... -->
<!--
<open url="https://foo.bar.com/lenya/default/authoring/index.html?lenya.usecase=open" method="GET"/>
-->
<save url="http://foo.bar.com/lenya/default/authoring/index.html?lenya.usecase=save" method="PUT"/>
<schemas>
<schema href="http://foo.bar.com/lenya/modules/docbook/schemas/simple.rng" type="RelaxNG"/>
<schema href="http://foo.bar.com/lenya/modules/docbook/schemas/default.rng" type="RelaxNG"/>
</schemas>
<styles>
<style href="http://foo.bar.com/lenya/modules/xhtml/styles/default.xsl"/>
<style href="http://foo.bar.com/lenya/modules/xhtml/styles/simple.xsl"/>
</styles>
</edit>
<!-- NOTE: What about delivering this as package, e.g. with a MANIFEST included? -->
<new>
<templates uri="http://foo.bar/templates"/>
</new>
<navigation>
<sitetree href=""/>
<topicmap href=""/>
<search type="simple">
<uri="http://search.msn.com/results.aspx?format=rss&FORM=ZZRE"/>
<query-string-parameter name="q"/>
<response type="rss"/>
</search>
<search type="simple">
<uri="http://www.google.com/search?hl=en&btnG=Google+Search"/>
<query-string-parameter name="q"/>
<response type="html"/>
</search>
</navigation>
</introspection>
]]>
</pre>
<p>
The version of introspection is given by the following namespace convention: http://www.wyona.org/neutron/VERSION
</p>
<h3>Backward Compatibility</h3>
<p>
If the client supports higher versions of the introspection spec than the server can deliver, but
the client still offers the lower version introspection parsers with the correct internal mapping.
</p>
<h3>Forward Compatibility</h3>
<p>
If the client introspection implementation version is lower than the introspection version which
is delivered by the server, then one would assume the client to throw a warning, but nevertheless the client should try to handle this newer version as good as possible. But this can only work if the spec is enhanced only (e.g. adding an attribute or element), and never really changed. Another solution might be that the client adds its supported introspection versions to the HTTP header of the GET request to retrieve the introspection from the server, e.g. OSR-101-Version: 1.0.
</p>
<a name="authentication"/>
<h2>Authentication</h2>
<p>
<ul>
<li><a href="http://httpd.apache.org/docs/1.3/howto/auth.html">http://httpd.apache.org/docs/1.3/howto/auth.html</a></li>
<li><a href="ftp://ftp.isi.edu/in-notes/rfc2616.txt">HTTP Credentials</a></li>
<li><a href="http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-08.html">Securing Atom</a></li>
<li>What about client certificates?</li>
</ul>
</p>
<a name="authorization"/>
<h2>Authorization</h2>
<p>
TODO: What about multi-stage/step process, e.g. first dialog to enter username and password and second dialog to enter a pre-generated random number?
</p>
<p>
Response from Server to Client
<pre>
<![CDATA[
<?xml version="1.0"?>
<exception xmlns="http://www.wyona.org/neutron/1.0" type="authorization">
<message>Authorization denied for "URL" ...</message>
<authentication>
<login url="https://demo.phoenix.wyona.org/protected/?action=login-neutron">
<message>Login for realm 'phoenix-demo' ...</message>
<form>
<param description="Username" name="username"/>
<param description="Password" name="passwd"/>
</form>
</login>
<logout url="http://demo.phoenix.wyona.org/?action=logout"/>
</authentication>
</exception>
]]>
</pre>
</p>
<p>
Response from Client to Server
<pre>
<![CDATA[
<?xml version="1.0"?>
<authentication xmlns="http://www.wyona.org/neutron/1.0">
<param name="username">lenya</param>
<param name="passwd">levi</param>
</authentication>
]]>
</pre>
</p>
<a name="editing-new"/>
<h2>New</h2>
<p>
The action "New" allows to create a new document by selecting a template.
The CMS/server needs to provide a template listing to the client such that
the client can provide a dialog in order to let the user select a template.
The "New" action entails a "Save As" action in order to allow specifying a
new document name when actually saving.
</p>
<h3>Request</h3>
<p>
...
</p>
<h3>Response</h3>
<pre>
<![CDATA[
<?xml version="1.0"?>
<response xmlns="http://www.wyona.org/neutron/1.0" type="edit-new">
<edit-new>
<templates>
<template name="Letter" src="http://foo.bar/letter.xml"/>
<template name="Article" src="http://foo.bar/article.xml"/>
</templates>
</edit-new>
</response>
]]>
</pre>
<a name="editing-open"/>
<h2>Open</h2>
<p>
The action "Open" allows to open an existing document.
If the client has already a document loaded and a new document will be
opened, then the loaded document might be closed automatically (please also
see "Close" and "Save All").
</p>
<p>
The CMS needs to provide a directory listing to the client such that the
client can provide a dialog in order to let the user select a document.
</p>
<p>
When a user attempts to open a document, then the server needs to check if
the document might have been locked already respectively opened by another
user. If it has already been locked respectively opened by another user,
then the CMS needs to communicate to the client that this document is
currently locked and maybe provide a functionality to break the lock.
Otherwise the document needs to be locked on the server side if the document
is being opened.
</p>
<p>
The document path needs to be kept within the client in order to allow
saving to the original document on the server side.
</p>
<h3>Usecases</h3>
<ul>
<li>Open from Local Desktop</li>
<li>Open from Server (server does not support locking)</li>
<li>Open from Server (checkout with lock)</li>
<li>Open from Server (checkout without lock although server does support locking)</li>
</ul>
<h4>Open from Server with locking/checkout implemented</h4>
<p>
<pre>
<![CDATA[
<?xml version="1.0"?>
<exception xmlns="http://www.wyona.org/neutron/1.0" type="checkout">
<message>Document has already been checked-out by ...</message>
<checkout url="/hello/world.html">
<locked-by>Jimi Hendrix</locked-by>
<lock-date format="standard">1969.10.03T15:34:26</lock-date>
<!-- Optional. Depending on server implementation -->
<break-lock url="/hello/world.html?yanel.resource.usecase=break-lock"/>
</checkout>
</exception>
]]>
</pre>
</p>
<p>
How does the server respond to the "break-lock" request?
<ul>
<li>Server breaks lock, check-out for new user and returns content.</li>
<li>Server breaks lock and returns lock broken successfully, please retry opening again ...</li>
<li>Server responds breaking the lock failed for whatever reason.</li>
</ul>
</p>
<a name="editing-save"/>
<h2>Save</h2>
<p>
The "Save" action allows to save a document to the path which was selected
when loading the document with the "Open" action.
</p>
<p>
It might be assumed that no temporary copies are being used on the server
side, but rather the original document is being overwritten. This might lead
to the confusing situation, that changes on the server side can been seen,
which are only temporarily.
</p>
<h3>Usecases</h3>
<ul>
<li>Save to Local Desktop (default behaviour in case document has been opened from local desktop)</li>
<li>Save to Local Desktop (although document has been retrieved from server)</li>
<li>Save to Server (server does not support locking)</li>
<li>Save to Server temp version (in case server supports this functionality)</li>
<li>Save to Server (checkin, remove the lock)</li>
</ul>
<p>
If the server is able to save successfully, then it should return HTTP Status Code 200.
</p>
<p>
If the server cannot save the data, then it should return <a href="http://www.w3.org/Protocols/HTTP/HTRESP.html">HTTP Status Code 500</a> and a message.
</p>
<p>
<pre>
<![CDATA[
<?xml version="1.0"?>
<exception xmlns="http://www.wyona.org/neutron/1.0" type="checkin">
<message>Checkin failed, because document has been checked-out by ...</message>
<checkin url="/hello/world.html">
<locked-by>Jimi Hendrix</locked-by>
<lock-date format="standard">1969.10.03T15:34:26</lock-date>
<!-- Optional. Depending on server implementation -->
<break-lock url="/hello/world.html?yanel.resource.usecase=break-lock"/>
</checkin>
</exception>
]]>
</pre>
</p>
<p>If the server has trouble saving the data, e.g.</p>
<p>
<pre>
<![CDATA[
<?xml version="1.0"?>
<exception xmlns="http://www.wyona.org/neutron/1.0" type="data-not-well-formed">
<message>Received data is not well-formed XML ...</message>
<data-not-well-formed url="/hello/world.html">
<line number="45" message="element not closed"/>
</data-not-well-formed>
</exception>
]]>
</pre>
</p>
<a name="editing-save-as"/>
<h2>Save As</h2>
<p>
Get a tree
<a href="http://www.ietf.org/rfc/rfc2518.txt">Example 8.1.2</a>
</p>
<a name="editing-exit"/>
<h2>Exit</h2>
<p>
The "Exit" action allows to quit the client. If the user clicks on the
"Exit" menu item, then the client opens a dialog, where the user can select
the following buttons/options:
</p>
<ul>
<li>Save</li>
<li>Save As</li>
<li>Don't save (Exit but do not save)</li>
<li>Cancel (Do not exit)</li>
</ul>
<p>
If a lock has been created during opening, then this locks needs to be
removed at this point. In case the CMS would support breaking the lock by
another user, then the CMS should communicate a broken lock to the client.
</p>
<a name="editing-link-lookup"/>
<h2>Hypertext Link Lookup</h2>
<p>
The hypertext link lookup functionality allows to add a hypertext link to a
text. One selects part of a text and clicks on the link icon which is
triggering a request to the server(s) in order to provide the content resp.
interface for a link selecting dialog. One could imagine the following types
of dialogs:
</p>
<ul>
<li>Text Field to paste a link</li>
<li>Search Field</li>
<li>Simple resource list</li>
<li>Hierarchical resource listing (tree-view)</li>
<li>Topic Map with resource occurences (graph-view)</li>
</ul>
<h3>Response: Search Field</h3>
<pre>
<![CDATA[
<?xml version="1.0"?>
<response xmlns="http://www.wyona.org/neutron/1.0" type="edit-link">
<edit-link>
<search src="http://foo.bar/search"/>
</edit-link>
</response>
]]>
</pre>
<h3>Response: Simple List</h3>
<pre>
<![CDATA[
<?xml version="1.0"?>
<response xmlns="http://www.wyona.org/neutron/1.0" type="edit-link">
<edit-link>
<simple-list>
<link name="Archibald Alexander Leach" src="http://foo.bar/leach.pdf"/>
<link name="Cary Grant" src="http://foor.bar/cary_grant.html"/>
</simple-list>
</edit-link>
</response>
]]>
</pre>
<a name="search"/>
<h2>Search</h2>
<p>
In the case of OpenOffice.org one can add new search engines by clicking on
Tools --> Options --> Internet --> Search
</p>
<p>
As an exchange format one might want to use the <a
href="http://opensearch.a9.com/">OpenSearch RSS</a>.
</p>
<a name="workflow"/>
<h2>Workflow</h2>
<p>
...
</p>
<hr/>
<a name="commentaries"/>
<h2>Commentaries</h2>
<h3>April 20, 2006 Commentary (Andreas Wuest)</h3>
<h4>Sessions</h4>
<ul>
<li><p>"The communication between the client and server can be initialized by introspection.": it is not clear if this means that some kind of sessions is initiated between the client and the server. IMHO, introspection should NOT initiate a session, since this is simply a query operation on what capabilities the server has.</p></li>
</ul>
<h4>Save As</h4>
<ul>
<li><p>We need a way to upload a file to the CMS without having previously issued a New or an Open. (This with regard to the CMSConnector for uploading attachments from a mail client to the CMS.)</p></li>
</ul>
<h4>Directory Listing</h4>
<ul>
<li><p>It should be possible to query the directory tree, starting from the root. The server should not return the complete tree, but only the content of the queried directory node.</p></li>
</ul>
<h4>Asset Type Querying</h4>
<ul>
<li><p>I assume that the list of legal asset types is provided via the introspection file. What I am thinking about though is a way for the server to PROPOSE an asset type for a given MIME type. Example: CMSConnector wants to upload an attachment. Before saving, CMSConnector somehow communicates the MIME type of the attachment to the server, and the server then proposes a suitable asset type for this MIME type.</p></li>
</ul>
<h4>Authentication</h4>
<ul>
<li><p>Each operation should support authentication of the client.</p>
<ul>
<li><p>Simple username/password tuple:</p>
<ul>
<li><p>Ways of identification:</p>
<ul>
<li><p>session cookie</p>
<ul>
<li><p>pros:</p>
<ul>
<li><p>authentication only once per session</p></li>
</ul>
</li>
<li><p>cons:</p>
<ul>
<li><p>needs sessions semantics</p></li>
<li><p>when does the session cookie expire if there is no normal exit</p></li>
</ul>
</li>
</ul>
</li>
<li><p>username/password is supplied with each operation</p></li>
</ul>
</li>
</ul>
</li>
<li>Challenge/Response</li>
<li>Client certificate</li>
</ul>
</li>
</ul>
<h4>Security</h4>
</body>
</html>