index.html
119 KB
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
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Compound Document Use Cases and Requirements Version 2.0</title><style type="text/css">
code { font-family: monospace; }
.scrap td { background-color: #d5dee3;}
table.scrap {margin-bottom: 1em }
div.constraint,
div.issue,
div.note,
div.notice { margin-left: 2em; }
ol.enumar { list-style-type: decimal; }
ol.enumla { list-style-type: lower-alpha; }
ol.enumlr { list-style-type: lower-roman; }
ol.enumua { list-style-type: upper-alpha; }
ol.enumur { list-style-type: upper-roman; }
div.exampleInner pre { margin-left: 1em;
margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
border-top-width: 4px;
border-top-style: double;
border-top-color: #d3d3d3;
border-bottom-width: 4px;
border-bottom-style: double;
border-bottom-color: #d3d3d3;
padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a></p>
<h1><a name="title" id="title"></a>Compound Document Use Cases and Requirements Version 2.0</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Draft 19 December 2005</h2><dl><dt>This version:</dt><dd>
<a href="http://www.w3.org/TR/2005/WD-CDFReqs-20051219/">http://www.w3.org/TR/2005/WD-CDFReqs-20051219/</a>
</dd><dt>Latest version:</dt><dd>
<a href="http://www.w3.org/TR/CDFReqs/">http://www.w3.org/TR/CDFReqs/</a>
</dd><dt>Previous version:</dt><dd>
<a href="http://www.w3.org/TR/2005/WD-CDRReqs-20050809/">http://www.w3.org/TR/2005/WD-CDRReqs-20050809/</a>
</dd><dt>Editors:</dt><dd>Steve Speicher, IBM Corporation</dd><dd>Petri Vuorimaa, Helsinki University of Technology</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2005 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr /><div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
This document describes the use cases for a framework
that combines documents and the set of requirements for
such a framework.
</p></div><div>
<h2><a name="status" id="status"></a>Status of this Document</h2><p>
<em>This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. A list of current W3C publications and the latest
revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
http://www.w3.org/TR/.</em>
</p><p>This is the first <a href="http://www.w3.org/2004/02/Process-20040205/tr.html#RecsWD">Working
Draft</a> of the Compound Document Use Cases and Requirements 2.0
document. It
has been produced by the <a href="http://www.w3.org/2004/CDF/">Compound
Document Formats Working Group</a>, which is part of the <a href="http://www.w3.org/2006/rwc/Activity">Rich Web Clients Activity</a>.</p><p>This revision adds additional use cases and requirements for compound documents by inclusion to the <a href="http://www.w3.org/TR/CDRReqs/">previous Working Draft</a> of <em>Compound Documents by Reference Use Cases and Requirements 1.0</em>, which is now published as a W3C Note.</p><p>
This is a Working Draft and is expected to change. The
CDF Working Group does not expect this document
to become a Recommendation. This document, after review and
refinement, will be published and maintained as a
Working Group Note.
</p><p>
In parallel, the CDF Working Group is producing a specification
that combines document formats, and meets the
requirements listed here. The requirements are intented to cover
combining formats using either by reference (CDR) or by inclusion
(CDI) techniques unless otherwise noted.
</p><p>
Comments and discussion on this document should be sent to
<a href="mailto:public-cdf@w3.org">public-cdf@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/public-cdf/">public archives</a>).
</p><p>
Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite
this document as other than work in progress.
</p></div><div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1 <a href="#introduction">Introduction</a><br />
1.1 <a href="#approach">Approach</a><br />
1.1.1 <a href="#phases-of-work">Phases of Work</a><br />
1.1.2 <a href="#intro-by-reference">By Reference</a><br />
1.1.3 <a href="#intro-by-inclusion">By Inclusion</a><br />
1.2 <a href="#rich_multimedia_content_definition">Definition of Rich Multimedia Content</a><br />
1.3 <a href="#relationships-with-other">Relationships With Other Technologies</a><br />
1.3.1 <a href="#relationships-html-xhtml">HTML and XHTML</a><br />
1.3.2 <a href="#relationships-xmlid">XML:id</a><br />
1.3.3 <a href="#relationships-xlink">XLink</a><br />
1.3.4 <a href="#relationships-xinclude">XInclude</a><br />
1.3.5 <a href="#relationships-xmlevents">XML Events</a><br />
1.3.6 <a href="#relationships-css">CSS</a><br />
1.3.7 <a href="#relationships-dom">DOM</a><br />
1.3.8 <a href="#relationships-svg">SVG</a><br />
1.3.9 <a href="#relationships-mathml">MathML</a><br />
1.3.10 <a href="#relationships-forms">XForms</a><br />
1.3.11 <a href="#relationships-smil">SMIL</a><br />
1.3.12 <a href="#relationships-xbl">XBL</a><br />
1.3.13 <a href="#relationship-xhtml-voice">XHTML + Voice</a><br />
1.3.14 <a href="#relationships-soap-attachments">SOAP Attachments and Optimization Technologies</a><br />
1.3.15 <a href="#relationships-open-document">OASIS's Open Document Format</a><br />
1.4 <a href="#terms">Definition of Terms</a><br />
1.5 <a href="#who_what_will_implement_the_specification">Who/what will implement the specification</a><br />
1.5.1 <a href="#authoringtools">Authoring tools and content production systems</a><br />
1.5.2 <a href="#useragents">User agents, such as browsers and plug-ins</a><br />
1.5.3 <a href="#intermediaryprocessors">Intermediary Processors, content renderers</a><br />
2 <a href="#use-cases">Use Cases</a><br />
2.1 <a href="#web_publishing_broadcasting">Web Publishing and Broadcasting</a><br />
2.1.1 <a href="#usecase-news-service">Interactive News Service</a><br />
2.1.2 <a href="#usecase-web-portal">Web Portal</a><br />
2.1.3 <a href="#usecase-ticker">News or stock ticker</a><br />
2.1.4 <a href="#usecase-document-viewing">Document viewing</a><br />
2.1.5 <a href="#usecase-infotainment">Infotainment</a><br />
2.2 <a href="#usecase-web-applications">Web Applications</a><br />
2.2.1 <a href="#usecase-reservation-system">Reservation system</a><br />
2.2.2 <a href="#usecase-order-entry">Order entry system</a><br />
2.2.3 <a href="#usecase-online-shopping">On-line shopping</a><br />
2.2.4 <a href="#usecase-survey">Survey</a><br />
2.2.5 <a href="#usecase-web-games">Games</a><br />
2.2.6 <a href="#usecase-interactive-maps">Interactive maps</a><br />
2.3 <a href="#usecase-resident-applications">Resident Applications</a><br />
2.3.1 <a href="#usecase-pim">Personal Information Management</a><br />
2.3.2 <a href="#usecase-communication">Communication</a><br />
2.3.3 <a href="#usecase-idle-screen">Dynamic graphics as background or screen saver in mobile phone</a><br />
2.3.4 <a href="#usecase-document-viewing2">Document viewing</a><br />
2.3.5 <a href="#usecase-icon-bar">Interactive Icon bar</a><br />
2.3.6 <a href="#usecase-interactive-maps2">Interactive Maps</a><br />
2.4 <a href="#content_authoring_aggregation_deployment">Content Authoring, Aggregation and Deployment</a><br />
2.4.1 <a href="#personal-content-creation">Personal content creation</a><br />
2.4.2 <a href="#personal-content-management">Personal content management</a><br />
2.4.3 <a href="#web-logs">Web logs</a><br />
2.4.4 <a href="#content-aggregation">Content aggregation</a><br />
2.4.5 <a href="#professional-content-management">Professional content management</a><br />
2.5 <a href="#usecase-navigation">Navigation</a><br />
2.5.1 <a href="#svg-logo-ad">SVG used as logo or advertisement (no links in SVG).</a><br />
2.5.2 <a href="#svg-embedded-map">SVG embedded interactive map (links in SVG). </a><br />
2.5.3 <a href="#svg-images-animate-when-focused">Menu with SVG images that animate and expand when focused (no links in SVG)</a><br />
2.5.4 <a href="#embedded-svg-interactive">SVG image is embedded interactive part of the Web page (SVG has
links)</a><br />
2.6 <a href="#specific-use-cases">Specific Use Cases</a><br />
2.6.1 <a href="#usecase-sync-of-html-content">Synchronization of HTML content with audio visual content:</a><br />
2.6.2 <a href="#usecase-animated-svg-icons">Animated SVG icons in HTML menu</a><br />
2.6.3 <a href="#usecase-poll-results">Visualization of polling results in HTML page</a><br />
3 <a href="#requirements">Requirements</a><br />
3.1 <a href="#requirements_cdr">Framework</a><br />
3.1.1 <a href="#requirements_cdr_general">General Framework</a><br />
3.1.2 <a href="#reqmt_cdr_ref">CDR Framework</a><br />
3.1.3 <a href="#reqmt_cdr_incl">CDI Framework</a><br />
3.2 <a href="#high_level_rich_multimedia_content_requirements">WICD Core</a><br />
3.2.1 <a href="#reqmt-wicd-core-general">General WICD Core</a><br />
3.2.2 <a href="#reqmt-wicd-core-ref">CDR WICD Core</a><br />
3.2.3 <a href="#reqmt-wicd-core-incl">CDI WICD Core</a><br />
3.3 <a href="#rich_multimedia_content_requirements">CDR WICD Profile 1</a><br />
3.3.1 <a href="#reqmt-wicd-prof1-mobile">CDR WICD Profile 1 - Mobile</a><br />
3.3.2 <a href="#reqmt-wicd-prof1-full">CDR WICD Profile 1 - Full</a><br />
3.4 <a href="#rich_multimedia_content_requirements_prof2">CDI & CDR WICD Profile 2</a><br />
3.4.1 <a href="#reqmt-wicd-prof2-mobile">CDI WICD Profile 2 - Mobile</a><br />
3.4.2 <a href="#reqmt-wicd-prof2-full">CDI WICD Profile 2 - Full</a><br />
</p>
<h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A <a href="#references">References</a> (Non-Normative)<br />
B <a href="#acknowledgements">Acknowledgements</a> (Non-Normative)<br />
C <a href="#changes-log">Changes Log</a> (Non-Normative)<br />
D <a href="#todos">Remaining items to complete this document</a> (Non-Normative)<br />
</p></div><hr /><div class="body"><div class="div1">
<h2><a name="introduction" id="introduction"></a>1 Introduction</h2><div class="div2">
<h3><a name="approach" id="approach"></a>1.1 Approach</h3><p>The Compound Document Formats Working Group is producing
recommendations on combining separate component languages
(e.g. XML-based languages, elements and attributes from
separate vocabularies), like XHTML, SVG, XForms, MathML, and
SMIL, with a focus on user interface markups. When combining
user interface markups, specific problems have to be resolved
that are not addressed by the individual markups
specifications, such as the propagation of events across
markups, the combination of rendering or the user interaction
model with a combined document. The Compound Document Formats
working group will address these types of problems. This work
is divided in phases and two technical solutions: combining
by reference and by inclusion.</p><p>The group is addressing the semantics of combining markups,
which goes beyond the mechanics and syntactical elements used
to combine markups. The semantic of combining markup is, to a
large extent, specific to any two markups being combined. For
example, including SVG markup in an XHTML document can be done
in various ways and there is a need to define how the
combination is done and what it means, especially with regards
to issues mentioned above (such as event propagation, user
interactions or rendering). Because defining the combined
semantics is complex, because the group needs to deliver a
test suite and specific conformance requirements (see <a href="http://www.w3.org/2004/CDF/admin/charter">charter</a>)
and because there is a growing request to support specific
versions of specific markups, the group will initially produce
a specification that mandates specific versions of specific
markup profiles. However, as explained in the following
section, the group will structure its specification work such
that generic combination concepts and techniques are part of a
framework specification so that they can be easily referenced
and reused in other contexts or in future specifications this
group produces.</p><p>The use cases and requirements in this document will cover
both combining by reference and inclusion, unless otherwise noted.</p><div class="div3">
<h4><a name="phases-of-work" id="phases-of-work"></a>1.1.1 Phases of Work</h4><p>The phases of work lists a set of languages (with their
profiles) that are combined. As the languages differ by
their features and properties, different issues come up when
combining together different languages. Therefore, the phase
constrains the issues that are currently solved.</p><p>The standardization starts with a limited set of
languages. Once issues on these languages are solved, a next
larger package is started. The following phases contain more
languages and therefore, the corresponding recommendations
solve a wider variety of combination issues. </p><p>Each phase may result in:</p><ul><li><p>a new version of the Compound Document Framework
specification</p></li><li><p>(at least) one specific Profile specification
that uses the corresponding Compound Document
Framework. Each Profile specification will include a list
of specific supported languages (and profiles thereof) and
also include any supplemental integration notes as
necessary beyond what is described in the
Framework.</p></li></ul></div><div class="div3">
<h4><a name="intro-by-reference" id="intro-by-reference"></a>1.1.2 By Reference</h4><p>The first technical solution for combining document
formats is combination by reference. This means that
documents using different languages (XML vocabularies) are linked
by a reference such as XLink references, XHTML <img>, <object>
and XForms instance src attributes.
This allows separate languages to work together,
but it allows implementations of the languages be
separated. </p><p>The standardized issues are for example, how events flow
in multi-document environment, how different documents are
accessed by the scripts, and how different languages should
cooperate in drawing to the screen (or other media).</p></div><div class="div3">
<h4><a name="intro-by-inclusion" id="intro-by-inclusion"></a>1.1.3 By Inclusion</h4><p>
A subsequent phase will address compound documents by inclusion, which is
combining more than one namespace vocabulary within the same document. For
example, a compound document with XHTML as the enclosing root schema which
contains nested XForms namespace elements, and SVG namespace elements,
and XML Events elements all in the same document. A compound document by
inclusion, may also contain reference to other separate documents, and
therefore may be a combination of inclusion and reference.
</p><p>
The standardization issues that will be addressed in the Compound
Documents by Inclusion Recommendation are how different namespace
vocabulary implementations will interact within the same document, and how
compound documents by inclusion should be loaded and processed by browser
user agents, as well as validated by authoring tools.
</p></div></div><div class="div2">
<h3><a name="rich_multimedia_content_definition" id="rich_multimedia_content_definition"></a>1.2 Definition of Rich Multimedia Content</h3><table border="1" bgcolor="yellow" summary="ToDo: Give WICD an appropriate introduction" id="todo.wicdintro"><tr><td align="left" valign="top"><b>ToDo</b></td><td align="right" valign="top">Give WICD an appropriate introduction</td></tr><tr><td align="left" valign="top"><b>Owner</b></td><td align="right" valign="top">Steve Speicher</td></tr><tr><td align="left" valign="top"><b>Note</b></td><td align="right" valign="top">WICD has been added abruptly, need to update the intro/rich contnent sections</td></tr><tr><td align="left" valign="top"><b>Links</b></td><td align="right" valign="top"></td></tr></table><p>
This specification addresses UI languages in order to
facilitate <b>rich multimedia content</b>, which can
include the following characteristics.
</p><p>
Throughout this specification, the term <b>Web Interactive Compound Document</b>
(WICD) will be used to refer to a specialized type of rich multimedia
content, that could be based on more that one compound languages.
</p><ul><li><p>
Graphically rich content, possibly including animated
background image.</p></li><li><p>
Content author/provider has exact control of the
presentation, including fonts, layout, color, etc.
</p></li><li><p>
Layout adaptation: layout can be based upon device
characteristics - screen size, color depth, resolution,
orientation.</p></li><li><p>
Navigation (forward/backwards tab, up/down/left/right,
accesskey, pointer, voice), graphical menus,
interactivity and animations.
</p></li><li><p>
Graphical menu systems where items have an animated
action when focused on.
</p></li><li><p>
Portable user interface.
</p></li><li><p>
Presentation can be customized to reflect a brand or
user's personality.
</p></li><li><p>
Skinnable user interface: the ability to use animations
and interactivity as a user interface "skin" or template
around other content.
</p></li><li><p>
Rich content for different contexts.
</p></li><li><p>
Dynamic content: documents that are generated on the fly or
which change over time
</p></li><li><p>
Interaction with mixed content, for example interacting with all the
parts (graphics, text, images, audio, video, voice and multimodal
interaction) of the mixed document.
</p></li><li><p>
Content adaptation, such as when a portal delivers a mixed
document with varying capabilities (textual content and
interactive animated content, for example) to a user which
has been aggregated from multiple rich content sources.
</p></li></ul><p>The following table shows existing W3C formats which are relevant to rich multimedia content. Each combination for which there is a requirement is
annotated with comments. This is here to
show the relationship between current W3C recommendations and
the definition of rich multimedia content: <a href="#rich_multimedia_content_definition"><b>1.2 Definition of Rich Multimedia Content</b></a>.</p><table rules="all" frame="box"><thead><tr><th></th><th>XHTML + CSS</th><th>SVG</th><th>SMIL</th><th>XForms</th><th>VoiceXML</th><th>XBL</th><th>DOM/Scripting</th></tr></thead><tbody><tr><th align="left">Graphically rich content, possibly including animated
background image</th><td>Need CSS's 'background-*' properties</td><td>Need animated graphics facility of SVG</td><td>SMIL supports z-order. Hence, animated or non-animated background image are easy to make in SMIL.</td><td>(not directly applicable)</td><td>(not directly applicable)</td><td>(not directly applicable)</td><td>(not directly applicable)</td></tr><tr><th align="left">Content author/provider has exact control of the presentation, including fonts, layout, color, etc...</th><td>For when author/provider requires exact control in flowable scenarios</td><td>For when author/provider requires exact control in fixed canvas scenarios</td><td>SMIL provides an exact control of the main document layout and it uses other media types such as XHTML or PNG for the content.</td><td>(not directly applicable)</td><td>Author exact control of audio presentation when media=aural or for multimodal presentation</td><td>(not directly applicable)</td><td>(not directly applicable)</td></tr><tr><th align="left">Layout adaptation: layout can be based upon device characteristics - screen size, color depth, resolution, orientation</th><td>For some scenarios, CSS box model layout and @media will be part of solution</td><td>For some scenarios, scalable graphics will be part of the solution</td><td>SMIL BasicContentControl (including <smil:switch>) is the module that provides this functionality.</td><td>In XForms, the content is separated from the presentation, and
thus it support layout adaptation of forms.</td><td>Allows author to provide an aural presentation when media=aural.</td><td>(not directly applicable)</td><td>(not directly applicable)</td></tr><tr><th align="left">Navigation (forward/backwards tab, up/down/left/right, accesskey, pointer, voice), graphical menus, interactivity and animations</th><td>Need XHTML <form> elements to define navigation points</td><td>For graphical menus, rich interactivity and animations</td><td>SMIL Linking module provides this functionality</td><td>For device-independent representation of human-computer interaction</td><td>For voice</td><td>(not directly applicable)</td><td>For when the author requires advanced behavior</td></tr><tr><th align="left">Menu system e.g., items get animated when focused</th><td>For some scenarios, XHTML+CSS is sufficient for menus</td><td>For rich UI and animation</td><td>Menus can be done in SMIL, but it can be cumbersome because each menu item needs to be in a separate file. Scripting could also be used in conjunction with referenced XHTML content.</td><td>Menus could be presented as forms with help of XBL</td><td>(not directly applicable)</td><td>Allows menus to be abstracted as reusable components</td><td>Often, menus require scripting facilities</td></tr><tr><th align="left">Portable user interface</th><td>For some scenarios, XHTML+CSS is sufficient for portable UIs</td><td>For rich UI and animation</td><td>Menus can be done in SMIL, but it can be cumbersome because each menu item needs to be in a separate file. Scripting could also be used in conjunction with referenced XHTML content.</td><td>For device-independent representation of human-computer interaction</td><td>For voice-based user interfaces</td><td>Allows menus to be abstracted and reskinned to adapt to different
platforms</td><td>Often, XBL components require client-side scripting</td></tr><tr><th align="left">Presentation can be customized to reflect brand or user's personality</th><td>For some scenarios, XHTML+bitmaps is sufficient</td><td>For some scenarios, SVG's richness is a requirement</td><td>SMIL CustomTestAttributes module provides this functionality.</td><td>(not directly applicable)</td><td>(not directly applicable)</td><td>Allows presentation elements to be abstracted and reskinned</td><td>Client-side scripting is often used for presentation customization</td></tr><tr><th align="left">Skinnable user interface e.g., ability to skin a document with animations and interactivity. </th><td>XHTML+CSS alone are not sufficient for skinnable UI</td><td>For rich graphics, animations and rich interactivity</td><td>SMIL controls the main document layout and all content is customizable. Test module provides ability to select appropriate content.</td><td>XForms provides the definition of the abstract UI components before skinning is applied</td><td>If you want to skin for voice</td><td>Allows UI elements to be abstracted and reskinned</td><td>Often, XBL components require client-side scripting</td></tr></tbody></table></div><div class="div2">
<h3><a name="relationships-with-other" id="relationships-with-other"></a>1.3 Relationships With Other Technologies</h3><p>There are many technologies that allow combining different
languages. Most extensible languages provide this
feature. The combining technologies and issues can be divided
in two categories. The first category is how the combining
is described. The second category is how the semantics of
combining is understood. Each language specifies the first
category. The combining recommendations try to solve the
second.</p><div class="div3">
<h4><a name="relationships-html-xhtml" id="relationships-html-xhtml"></a>1.3.1 HTML and XHTML</h4><p>HTML has an <object> element. This element can be used to
combine by reference. The <object> element provides a way to
link to external documents.</p></div><div class="div3">
<h4><a name="relationships-xmlid" id="relationships-xmlid"></a>1.3.2 XML:id</h4><p>A mechanism allowing unique element identifiers to be recognized by all
conformant XML processors, whether they validate or not, is desirable in
making XML sub-resource linking robust. The <em>xml:id</em> specification
allows authors to identify elements with IDs that can be recognized by any
processor without regard to how, or if, any internal or external
declarations are available.
</p></div><div class="div3">
<h4><a name="relationships-xlink" id="relationships-xlink"></a>1.3.3 XLink</h4><p>Xlink specifies a generic reusable vocabulary for links
in XML documents. An XLink may be specified on an arbitrary
element in such a way that an XLink enabled processor will
be able to understand the linking semantics of said element. A variety of
linking behaviors (embedding, hyperlinking, etc.) may be further
described using additional linking metadata.</p></div><div class="div3">
<h4><a name="relationships-xinclude" id="relationships-xinclude"></a>1.3.4 XInclude</h4><p>XInclude specifies how to combine different infosets
together. This approach may be used for combination by
inclusion.</p><p>After the XInclude markup is processed, the WG's produced
recommendations will specify the semantics on how the application
should understand the compound document.</p></div><div class="div3">
<h4><a name="relationships-xmlevents" id="relationships-xmlevents"></a>1.3.5 XML Events</h4><p>XML Events defines an extensible event specification method for XML.
It provides for new event types without requiring modification to the
DOM or document schema. It also allows for integration into other host
languages.
</p></div><div class="div3">
<h4><a name="relationships-css" id="relationships-css"></a>1.3.6 CSS</h4><p>CSS is a style sheet language that allows authors and users to attach
style (e.g., fonts and spacing) to structured documents (e.g., HTML
documents and XML applications). CSS enables the separation the
presentation style of documents from the content of documents.
</p></div><div class="div3">
<h4><a name="relationships-dom" id="relationships-dom"></a>1.3.7 DOM</h4><p>The DOM Core specification is a platform- and language-neutral
interface that allows programs and scripts to dynamically access and
update the content, structure and style of documents.
</p><p>The DOM Events specification is a generic platform- and
language-neutral event system which allows registration of event handlers,
describes event flow through a tree structure, and provides basic
contextual information for each event.
</p></div><div class="div3">
<h4><a name="relationships-svg" id="relationships-svg"></a>1.3.8 SVG</h4><p>SVG has a <foreignObject> element. This element can be used
to combine by reference. The <foreignObject> element
provides a way to link to external documents.</p></div><div class="div3">
<h4><a name="relationships-mathml" id="relationships-mathml"></a>1.3.9 MathML</h4><p>MathML is an XML application for describing mathematical notation and
capturing both its structure and content.
</p></div><div class="div3">
<h4><a name="relationships-forms" id="relationships-forms"></a>1.3.10 XForms</h4><p>XForms is a schema designed to split documents into three
parts: the XForms model, the instance data, and the user
interface. It provides a mechanism for expressing the data
and intent of a form and allowing browser/renderers the
flexibility to present the information most suitable for the
device currently rendering the form. XForms supports
compound document by inclusion by design since it is not a
free-standing document type, and was always meant to be
enclosed by a root document.</p></div><div class="div3">
<h4><a name="relationships-smil" id="relationships-smil"></a>1.3.11 SMIL</h4><p>SMIL technologies are closely related to combining by
reference. SMIL provides mechanisms (e.g., <animation>, <audio>
and <video> elements) to combine content and synchronize them in time.</p></div><div class="div3">
<h4><a name="relationships-xbl" id="relationships-xbl"></a>1.3.12 XBL</h4><p>XBL is a mechanism for defining the presentation and interactive
behavior of elements described in various namespaces.
</p></div><div class="div3">
<h4><a name="relationship-xhtml-voice" id="relationship-xhtml-voice"></a>1.3.13 XHTML + Voice</h4><p>The XHTML+Voice profile is designed for Web clients that
support visual and spoken interaction. The XHTML+Voice
profile brings spoken interaction to standard web content by
integrating a set of mature web technologies such as XHTML
and XML Events with XML vocabularies developed as part of
the W3C Speech Interface Framework. The profile includes
voice modules that support speech synthesis, speech dialogs,
command and control, speech grammars, and the ability to
attach Voice handlers for responding to specific DOM events,
thereby re-using the event model familiar to web
developers. Voice interaction features are integrated
directly with XHTML and CSS, and can consequently be used
directly within XHTML content. The definition of the
XHMTL+Voice profile is a compound document profile.</p></div><div class="div3">
<h4><a name="relationships-soap-attachments" id="relationships-soap-attachments"></a>1.3.14 SOAP Attachments and Optimization Technologies</h4><p>SOAP Attachments provide a way to divide documents into
several pieces for more efficient serialization and subsequent
recombination. For the WG's produced recommendations,
SOAP Attachments are similar in scope to the XInclude technology,
the combining technology operates and provides semantic
information on top of these serialization issues.</p></div><div class="div3">
<h4><a name="relationships-open-document" id="relationships-open-document"></a>1.3.15 OASIS's Open Document Format</h4><p>The OASIS effort is targeted at office productivity
applications, such as word processors, spreadsheets or
presentation authoring tools. The work is focused on
representing the full information contained in documents
that are created and edited with such tools in an
interoperable manner. On the other hand, the CDF effort is
focused on combining formats for web publication and has a
lot of focus on user agent environment, and runtime
behavior. For example, the CDF Working Group efforts will focus on issues
such as the runtime interaction model for documents
including components from different XML formats. This is not
addressed by the Open Document Format specification. The
Open Document Format, on the other hand, specifies an office
application compatible style model, page layouts, index
generations, text fields, table formulas which the CDF
specifications will not address.</p></div></div><div class="div2">
<h3><a name="terms" id="terms"></a>1.4 Definition of Terms</h3><p>The working group has decided to use following terms in the
work and this document.</p><dl><dt class="label">Compound document</dt><dd><p>
The compound document is a
document that combines separate component languages either
by reference or by inclusion.</p></dd><dt class="label">Root document</dt><dd><p>In the case of combining by reference, one compound
document may be a collection of several separate
documents.</p><p>The top-most (e.g. document not having any references
to it) compound document is called Root document.</p></dd><dt class="label">Parent document</dt><dd><p>In the case of combining by reference, one compound
document may be a collection of several separate
documents.</p><p>The document that references another document is called
Parent document. The top-most parent document is also called
Root document.</p></dd><dt class="label">Child document</dt><dd><p>In the case of combining by reference, one compound
document may be a collection of several separate
documents.</p><p>The document that is referenced is called Child
document. If the Child document references other documents,
it is also called Parent document.</p></dd><dt class="label">Root language</dt><dd><p>In the case of combining by inclusion, the language of the
document's root element.</p><p>The top-most language in a compound document is called
the Root language.</p></dd><dt class="label">Parent language</dt><dd><p>In the case of combining by inclusion, the language of
an element or attributes parent if the namespaces differ.</p><p>The language that includes another language is called the
Parent language. The top-most parent language is also called
the Root language.
</p></dd><dt class="label">Child language</dt><dd><p>In the case of combining by inclusion, the language that is nested
within a language from another namespace.</p><p>The language that is included is called the Child
language. If the Child language includes other languages,
it is also called a Parent language.</p></dd><dt class="label">User Agent</dt><dd><p>
See <a href="http://www.w3.org/TR/di-gloss/#def-user-agent">definition</a> in Device Independence Glossary document.</p></dd><dt class="label">Component Language</dt><dd><p>Component language refers to an XML-based language (like XHTML and SVG) with its own elements and attributes.</p></dd></dl><table border="1" bgcolor="yellow" summary="ToDo: Should we add 'framework' and 'profile' to definitions" id="todo-defs-fwk-prof"><tr><td align="left" valign="top"><b>ToDo</b></td><td align="right" valign="top">Should we add 'framework' and 'profile' to definitions</td></tr><tr><td align="left" valign="top"><b>Owner</b></td><td align="right" valign="top">Steve Speicher</td></tr><tr><td align="left" valign="top"><b>Note</b></td><td align="right" valign="top"></td></tr><tr><td align="left" valign="top"><b>Links</b></td><td align="right" valign="top"></td></tr></table></div><div class="div2">
<h3><a name="who_what_will_implement_the_specification" id="who_what_will_implement_the_specification"></a>1.5 Who/what will implement the specification</h3><div class="div3">
<h4><a name="authoringtools" id="authoringtools"></a>1.5.1 Authoring tools and content production systems</h4><p>Compound documents can be authored by a variety of means including:</p><ul><li><p>Hand editing with a text editor</p></li><li><p>Dynamic generation via a Web servers or other back end systems</p></li><li><p>Via authoring tools which focus on the component languages (an
XHTML authoring tool)</p></li><li><p>Via authoring tools which focus on compound documents (a "CDF
authoring tool")</p></li></ul><p>It is expected that there will be multiple categories of CDF authoring
tools. Here are some examples:</p><ul><li><p>Document-centric authoring tools to create content which mixes static
text and graphics for the purpose of publishing on the Web</p></li><li><p>Multimedia-centric authoring tools for creating time-based, interactive
content (a movie or game, for example)</p></li><li><p>Application-centric authoring tools to create user interfaces</p></li><li><p>Forms-centric authoring tools to create data templates</p></li><li><p>Device-independent authoring tools for creating content that can be
adapted to different user requirements and across different media</p></li></ul></div><div class="div3">
<h4><a name="useragents" id="useragents"></a>1.5.2 User agents, such as browsers and plug-ins</h4><p>Depending on the system, CDF content will be viewed in a variety of ways:</p><ul><li><p>Via native support within a browser which is
conformant with CDF specification(s)</p></li><li><p>Via a browser plug-in which registers itself as a
handler for CDF content</p></li><li><p>Via a dedicated CDF viewing application</p></li><li><p>Via browser fallback compatibility (e.g., the
browser treats CDF files as XHTML content)</p></li><li><p>Via accessibility tools such as screen
readers</p></li></ul></div><div class="div3">
<h4><a name="intermediaryprocessors" id="intermediaryprocessors"></a>1.5.3 Intermediary Processors, content renderers</h4><p>Systems that process, combine, re-order, re-format or
otherwise render content based on context. An example
is a content rendering engine which takes content in a
device neutral form and renders it appropriately
according to particular device or bearer characteristics
(such as screen size or bandwidth).</p></div></div></div><div class="div1">
<h2><a name="use-cases" id="use-cases"></a>2 Use Cases</h2><p>The W3C and other bodies have created multiple XML syntaxes
for various purposes, such as XHTML for on-line document
viewing, SVG for 2D vector graphics, XForms for form processing
or SMIL for multi-media
synchronization. While there has been a lot of interest for
these individual solutions, there has been a growing demand for
a solution that would let end-users use them together to define
a single piece of content. The individual markups as those just
mentioned have great features, but these features become even
more compelling when combined. For example, being able to
display scalable 2D images in XHTML pages provides the ability
to define pages which can be printed with high
quality. Similarly, using SVG images in an XHTML table provides
an easy way to layout SVG images in a table.</p><p>There is a demand for letting content creators combine
markups so as to create richer documents, containing multi-media
information: text, forms, graphics, audio and video. For that reason,
the main use case for the CDF activity is the definition of rich
multimedia content, as defined in <a href="#rich_multimedia_content_definition"><b>1.2 Definition of Rich Multimedia Content</b></a>.</p><div class="div2">
<h3><a name="web_publishing_broadcasting" id="web_publishing_broadcasting"></a>2.1 Web Publishing and Broadcasting</h3><p>
Services that mix text, audio, video and interactive elements to deliver information.
</p><div class="div3">
<h4><a name="usecase-news-service" id="usecase-news-service"></a>2.1.1 Interactive News Service</h4><p>
An interactive news service may provide the user with
multimedia news content comprising traditional text and
images, but also audio and video reports as well as
diagrams which react to user behavior.
</p><div class="note"><p class="prefix"><b>Note:</b></p><p>Example: newspaper Web sites that offer interactive features which go beyond textual content offered in a print edition.</p></div></div><div class="div3">
<h4><a name="usecase-web-portal" id="usecase-web-portal"></a>2.1.2 Web Portal</h4><p>A "portal" application combines content and services from
multiple back-end sources across multiple integration
paths to create a cohesive user experience. Portals often
are customizable to user preferences and other factors and
therefore often produce dynamic content that is specific to
a particular user-request.</p></div><div class="div3">
<h4><a name="usecase-ticker" id="usecase-ticker"></a>2.1.3 News or stock ticker</h4><p>An animated "ticker" which displays dynamic data, such as
stock prices or current news headlines, can be displayed as
part of a larger page of more static information, such as a
news article.</p></div><div class="div3">
<h4><a name="usecase-document-viewing" id="usecase-document-viewing"></a>2.1.4 Document viewing</h4><p>The capability to view documents with preserved
formatting, layout, images and graphics and interactive
features such as zooming in and out and multi-page
handling.</p></div><div class="div3">
<h4><a name="usecase-infotainment" id="usecase-infotainment"></a>2.1.5 Infotainment</h4><p>Infotainment services
combine information and entertainment from different sources
into a single interactive service with compelling
presentation. The user experience for such services is often
a single "page" which displays multiple pieces of
content, each potentially of a different kind. These
services often require dynamic user interfaces that use
animation and other graphic effects to produce a pleasing
user interface.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>Example: mobile portals deployed by mobile network operators.</p></div></div></div><div class="div2">
<h3><a name="usecase-web-applications" id="usecase-web-applications"></a>2.2 Web Applications</h3><p>
Web applications typically have some form of programmatic
control, either on the client, on the server or a
combination of both. This document addresses client-side Web
applications only. They may run within the user agent, or
within another host application. A Web application is
typically downloaded on demand each time it is "executed",
allowing a developer to update the application for all users
when needed. Web applications are usually smaller than
regular desktop applications, and can have rich graphical
interactive interfaces.
</p><div class="div3">
<h4><a name="usecase-reservation-system" id="usecase-reservation-system"></a>2.2.1 Reservation system</h4><p>Interactive services which allow a user to book travel or
make other kinds of reservations by using graphically-rich
user interface. For instance, a user may use a calendar to
pick a departure or check-in date and a map to locate a
destination, with results represented as textual data for
confirmation.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>Example: online travel sites or airline
sites.</p></div></div><div class="div3">
<h4><a name="usecase-order-entry" id="usecase-order-entry"></a>2.2.2 Order entry system</h4><p>An application which might be used in the field to
process orders for goods or services.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>Examples: Parcel tracking application used by
delivery agents; order entry system used by a mobile sales
force.</p></div></div><div class="div3">
<h4><a name="usecase-online-shopping" id="usecase-online-shopping"></a>2.2.3 On-line shopping</h4><p>E-Commerce services which use interactive elements to
display goods and enable a shopping experience.</p></div><div class="div3">
<h4><a name="usecase-survey" id="usecase-survey"></a>2.2.4 Survey</h4><p>A survey application which provides a multi-part form
which can be stepped forward or backward and submitted in
one action.</p></div><div class="div3">
<h4><a name="usecase-web-games" id="usecase-web-games"></a>2.2.5 Games</h4><p>Interactive games that use animated content embedded
within a page and using elements within the page to actuate
functions within the game. For example, a simple painting
game where the painting occurs in the animated area but a
palate of colors are set outside of this area in the
non-animated area.
</p></div><div class="div3">
<h4><a name="usecase-interactive-maps" id="usecase-interactive-maps"></a>2.2.6 Interactive maps</h4><p>In a mapping application, the map itself may appear in an
animated inset, while controls that show or hide various
aspects of the map or zoom the view in or out may be located
outside the animated area.</p></div></div><div class="div2">
<h3><a name="usecase-resident-applications" id="usecase-resident-applications"></a>2.3 Resident Applications</h3><p>
These are applications which are resident or partially resident on
a device.
</p><div class="div3">
<h4><a name="usecase-pim" id="usecase-pim"></a>2.3.1 Personal Information Management</h4><p>To-do list, calendar entries and Calculator user interfaces.</p></div><div class="div3">
<h4><a name="usecase-communication" id="usecase-communication"></a>2.3.2 Communication</h4><p>Email, MMS, instant messaging, access to phone functions,
such as dialing a number, sending a text message, or
manipulation of the built-in address book (subject to
security and privacy considerations).</p></div><div class="div3">
<h4><a name="usecase-idle-screen" id="usecase-idle-screen"></a>2.3.3 Dynamic graphics as background or screen saver in mobile phone</h4><p>In a mobile phone, a Web application is set as background or screen
saver, and is dynamically updated depending on, for example, data from
the network or the time of day. This allows the user to have immediate
access to 'glancable' information, such as current weather conditions,
stock quotes, or more application-oriented information such as flight
departure data.</p></div><div class="div3">
<h4><a name="usecase-document-viewing2" id="usecase-document-viewing2"></a>2.3.4 Document viewing</h4><p>The capability to view documents with preserved
formatting, layout, images and graphics and interactive
features such as zooming in and out and multi-page
handling.</p></div><div class="div3">
<h4><a name="usecase-icon-bar" id="usecase-icon-bar"></a>2.3.5 Interactive Icon bar</h4><p>A set of icons,
representing destinations in a
portal or applications, which
animate when focused on.</p></div><div class="div3">
<h4><a name="usecase-interactive-maps2" id="usecase-interactive-maps2"></a>2.3.6 Interactive Maps</h4><p>Display of a map with interactive features such as
panning, zooming, level of detail, points of interest.</p></div></div><div class="div2">
<h3><a name="content_authoring_aggregation_deployment" id="content_authoring_aggregation_deployment"></a>2.4 Content Authoring, Aggregation and Deployment</h3><p>This class includes tools and applications for both personal
and professional content creation, management, and
distribution.</p><div class="div3">
<h4><a name="personal-content-creation" id="personal-content-creation"></a>2.4.1 Personal content creation</h4><p>Personal content is created by users themselves and, often, shared
with other users. In many cases, users want to combine different
content formats. A typical example is that use take a picture with
mobile phone, write short message about the excellent meal that he/she
had in the restaurant, and attach a map which shows the location of
the restaurant.</p></div><div class="div3">
<h4><a name="personal-content-management" id="personal-content-management"></a>2.4.2 Personal content management</h4><p>
Personal content management refers to storing your
personal media content including images, audio, video,
graphics, text, etc. It should be possible to link
different content items to each other, view them
simultaneously. In addition, the content management system
should support adaptation of the content for different
kinds of devices and sharing the content online with other
users. </p></div><div class="div3">
<h4><a name="web-logs" id="web-logs"></a>2.4.3 Web logs</h4><p>
Blogs are personal diaries that are published online. Many
bloggers try to create visually attractive content by
combining different content formats. </p></div><div class="div3">
<h4><a name="content-aggregation" id="content-aggregation"></a>2.4.4 Content aggregation</h4><p>
In content aggregation, content coming from different
sources is combined together. Web portals are typical
examples. Often, content aggregators have different
versions of the content offering for different delivery
channels and user groups. Therefore, content filtering and
transforming is often required. In addition, the content
aggregators want to maintain certain look and feel of
service across different devices and versions. Also, there
might be need for Digital Rights Management (DRM).
</p></div><div class="div3">
<h4><a name="professional-content-management" id="professional-content-management"></a>2.4.5 Professional content management</h4><p>
Most professional web sites use content management
systems, which provide means for version management,
access control, content versioning, etc. The content
itself is usually in several different formats.
</p></div></div><div class="div2">
<h3><a name="usecase-navigation" id="usecase-navigation"></a>2.5 Navigation</h3><div class="div3">
<h4><a name="svg-logo-ad" id="svg-logo-ad"></a>2.5.1 SVG used as logo or advertisement (no links in SVG).</h4><p>SVG images are used as embedded logos or advertisements (with
animations) in an XHTML document.
There are no links in the SVG images.
The user cannot focus the images, they are like bitmaps embedded by
<img>. </p></div><div class="div3">
<h4><a name="svg-embedded-map" id="svg-embedded-map"></a>2.5.2 SVG embedded interactive map (links in SVG). </h4><p>An SVG image, which is an interactive city map, is embedded inside an
XHTML page.
There are links inside the SVG image.
The user can navigate to the SVG map, which then gets focus.
When the map has focus the user can either navigate further into the
first link inside the map or skip the map and navigate further to the
next link in the XHTML document.</p></div><div class="div3">
<h4><a name="svg-images-animate-when-focused" id="svg-images-animate-when-focused"></a>2.5.3 Menu with SVG images that animate and expand when focused (no links in SVG)</h4><p>SVG images are used as menu icons, wrapped inside <a> elements, in an
XHTML document.
There are no links inside the SVG images.
When the user focuses a menu item, the icon expands and starts to
animate.
When the user moves to the next item, the animating icon returns to the
state it had before it had focus, and the next icon, which now gets
focus and starts to animate.</p></div><div class="div3">
<h4><a name="embedded-svg-interactive" id="embedded-svg-interactive"></a>2.5.4 SVG image is embedded interactive part of the Web page (SVG has
links)</h4><p>An SVG image is used as 2D-graphics in a Web page. The SVG image has
links.
The user can navigate directly from an XHTML link into the first link in
the SVG image; the SVG image is seamlessly integrated with the XHTML
page.
The user navigates directly from the last link inside the SVG image to
the next link, after the SVG image, in XHTML. </p><p>This is an alternative scenario in <a href="#svg-embedded-map"><b>2.5.2 SVG embedded interactive map (links in SVG). </b></a>.</p></div></div><div class="div2">
<h3><a name="specific-use-cases" id="specific-use-cases"></a>2.6 Specific Use Cases</h3><p>Whereas the use cases outlined above are general in nature, the following use cases go into more detail and specifically describe some of the implementation issues that require the use of compound document technology.</p><div class="div3">
<h4><a name="usecase-sync-of-html-content" id="usecase-sync-of-html-content"></a>2.6.1 Synchronization of HTML content with audio visual content:</h4><p>The description of an auction item on an auction service (a Web page)
includes a short video clip that describes the item. Lets
assume the user needs to watch the video clip in-full for
legal reasons before he is allowed to place a bid for this
item by typing the amount in an entry field and pressing the
"Place Bid" button on the same Web page.</p><p>User starts play-back of the video by selecting a button
on the page. This raises an event that starts playback of
the embedded video object. Once the video has ended the
embedded video object raises another event. This event
causes the "Place Bid" to become selectable in the HTML
page.</p><p>This use case includes several functionalities which are
not possible in HTML and the <object> element today: </p><ul><li><p>starting and stopping playback of an embedded video (or audio) in response to interaction with another HTML element</p></li><li><p>an embedded object generating an event that causes an update to the including HTML page (possibly with the help of JavaScript) without reloading this page</p></li></ul></div><div class="div3">
<h4><a name="usecase-animated-svg-icons" id="usecase-animated-svg-icons"></a>2.6.2 Animated SVG icons in HTML menu</h4><p>An HTML page includes a menu for the user to select
between different Web applications. Each menu item is a
single <a> element. Each anchor value consists of an SVG
graphics and a rich text label. Each SVG graphics must
scale to fit the same size rectangular bounding box
(position and size defined by the containing HTML+CSS
document), aspect ratio must be maintained when
scaling. Example:</p>
<h5><a name="scrap-usecase-animated-svg-icons" id="scrap-usecase-animated-svg-icons"></a>Animated SVG Icons Example</h5><table class="scrap" summary="Scrap"><tbody><tr><td><pre><a href="Web-application-1.html">
<object width="100%" data="menu-item-1.svg" />
Web Application Choice<em>1</em>
</a></pre></td></tr></tbody></table><p>The background image of the page (defined by background-image CSS property) must be visible through the 'holes' in the SVG graphics.</p><p>While the user designates an anchor without selecting it (see :hover pseudo class in HTML) the rendering of the anchor value should change as follows:</p><ul><li><p>background of the text part of the anchor changes to yellow</p></li><li><p>the SVG graphics plays an animation</p></li></ul><p>While the user activates an anchor (see active pseudo class in CSS) the rendering of the anchor value should change as follows: </p><ul><li><p>background of the text and SVG parts of the anchor changes to blue</p></li><li><p>the SVG graphics does not animate. Any running animation stops</p></li></ul><p>The following features can not be done with HTML + CSS alone, or cause significant overhead in the content:</p><ul><li><p>background image visible through the 'holes' of content rendered by a typical browser plug-in (or at least this is implementation dependent).</p></li><li><p>SVG content animate for the exact duration of an anchor being designated</p></li><li><p>reliable definition of dimension and aspect ratio of SVG content</p></li></ul></div><div class="div3">
<h4><a name="usecase-poll-results" id="usecase-poll-results"></a>2.6.3 Visualization of polling results in HTML page</h4><p>An HTML page allows to enter polling results for the three candidates of an election. As soon as (partial) results of the pole have been entered a pie chart on the same HTML page should be updated to visualize the entered data.</p><p>The HTML page consists of three entry fields to enter number of votes for each candidate. A JavaScript calculates the percentage of votes for each candidate and updates a pie chart in SVG immediately. </p><p>The key functionality that can not be done with the current integration of HTML and SVG via the <object> element is access from JavaScript to both documents.</p></div></div></div><div class="div1">
<h2><a name="requirements" id="requirements"></a>3 Requirements</h2><p>All the requirements regarding Compound Document Formats (CDF)
are listed in the following sections.</p><div class="div2">
<h3><a name="requirements_cdr" id="requirements_cdr"></a>3.1 Framework</h3><p>The following subsections will outline requirements for a framework
for CDF. These requirements will cover
general, compounding by reference (CDR) and by inclusion (CDI) techniques.</p><div class="div3">
<h4><a name="requirements_cdr_general" id="requirements_cdr_general"></a>3.1.1 General Framework</h4><p>These are general requirements that apply to both
compounding by reference (CDR) or inclusion (CDI).</p><div class="div4">
<h5><a name="reqmt-exploitexisting" id="reqmt-exploitexisting"></a>3.1.1.1 CDF MUST exploit existing specifications, favoring W3C
specifications wherever possible and limit the definition of new
markup unless absolutely required for integration purposes</h5><p>It is not the role of the Working Group to invent new
markup, but rather to specify rules by which existing markup
formats are combined.
</p></div><div class="div4">
<h5><a name="reqmt-baseset" id="reqmt-baseset"></a>3.1.1.2 CDF MUST specify a base set of formats, corresponding
profiles and versions</h5><p>Conformant implementations MUST support this base set.</p></div><div class="div4">
<h5><a name="reqmt-document-confirmance-criteria" id="reqmt-document-confirmance-criteria"></a>3.1.1.3 CDF Profiles MUST define clear document conformance criteria</h5><p>CDF Profile specifications must define what kinds of documents are conformant and non-conformant.</p></div><div class="div4">
<h5><a name="reqmt-useragent-conformance-criteria" id="reqmt-useragent-conformance-criteria"></a>3.1.1.4 CDF Profiles MUST define clear user agent conformance criteria</h5><p>CDF Profile specifications must define conformance rules for user agents.</p></div><div class="div4">
<h5><a name="reqmt-useragentidentifies" id="reqmt-useragentidentifies"></a>3.1.1.5 Each Profile MUST explain how a User Agent is able to identify it</h5><p>A CDF Profile content (that is, content which confirms to a language
profile built using its CDF Profile specification) will be unambiguously
identified as conforming to that language profile.</p><p>Content creators and viewer implementations will both better be
able to meet the conformance requirements of the CDF
specifications if such content can be unambiguously identified.
Use of a specific mime type will furthermore (through the use of
accept headers) allow servers to perform a simple check on whether
a suitable client is available.</p></div><div class="div4">
<h5><a name="reqmt-identificationofmarkup" id="reqmt-identificationofmarkup"></a>3.1.1.6 Each Profile MUST support identification of markup and versions in CDF documents</h5><p>Each Profile must provide a mechanism for uniquely identifying the
markups and versions used in a particular CDF documents. Ensure
that this information can be used in content negotiation.
</p><table border="1" bgcolor="yellow" summary="ToDo: Need to consolidate "identification of markup" requirements" id="content-type"><tr><td align="left" valign="top"><b>ToDo</b></td><td align="right" valign="top">Need to consolidate "identification of markup" requirements</td></tr><tr><td align="left" valign="top"><b>Owner</b></td><td align="right" valign="top">Steve Speicher</td></tr><tr><td align="left" valign="top"><b>Note</b></td><td align="right" valign="top">There appears to be information in at least 2 requirements, if not up to 4 </td></tr><tr><td align="left" valign="top"><b>Links</b></td><td align="right" valign="top"></td></tr></table></div><div class="div4">
<h5><a name="reqmt-advertisingsvg" id="reqmt-advertisingsvg"></a>3.1.1.7 Each Profile MUST support advertising the specific supported versions
of formats and capabilities in headers</h5><p>When a user agent makes a request for content, it must identify
the content types it can support. This is done by specifying the
mime-type, version, and profile information, for each supported
type of content, in the request. Using HTTP, this can be done by
either using the Accept, UAProf or Content-Feature headers.</p></div><div class="div4">
<h5><a name="reqmt-genericintegrationtechniques" id="reqmt-genericintegrationtechniques"></a>3.1.1.8 CDF MUST specify generic integration techniques</h5><p>These are techniques that will be applicable
beyond the set of formats, versions and profiles required by the
CDF spec.</p></div><div class="div4">
<h5><a name="reqmt-eventscrossnamespace" id="reqmt-eventscrossnamespace"></a>3.1.1.9 CDF MUST support event mechanisms that cross namespace boundaries</h5><p>Define consistent rules that specify how events pass to
components. In particular, provide rules that define the behavior
when events are passed across namespace boundaries.</p></div><div class="div4">
<h5><a name="reqmt-scriptability" id="reqmt-scriptability"></a>3.1.1.10 CDF MUST support scriptability</h5><p>Compound documents have to support scripting languages. The scripts
have to be able to access and modify the elements of both root and child
documents as well as root and integrated languages.</p></div><div class="div4">
<h5><a name="reqmt-nestinglevel" id="reqmt-nestinglevel"></a>3.1.1.11 CDF MUST specify the allowed nesting level of combinations</h5><p>Each CDF profile must define, whether there are restrictions to
number of nesting levels. For example, whether a referenced SVG can
itself reference another XHTML content.</p></div><div class="div4">
<h5><a name="reqmt-addingeventhandlers" id="reqmt-addingeventhandlers"></a>3.1.1.12 CDF profiles SHOULD provide a method for adding event
handlers using declarative markup for the formats it uses</h5><p>Event handlers contain instructions on how to react to certain
event. These can be written either using a scripting language or a
declarative (i.e., markup) language. The CDF specification should
provide a method to add event handlers both to parent and child
documents or languages. If a CDF profile contains a markup language that
supports declarative event handlers then the CDF profile should
also support event handlers defined using markup.
</p></div><div class="div4">
<h5><a name="reqmt-transport" id="reqmt-transport"></a>3.1.1.13 CDF must define its integration into the Web
Architecture. It must include delivery over HTTP and should also
strive to be transport independent</h5><p>CDF profile documents must describe how they integrate into the
Web Architecture, particularly in the areas of media types and
transfer/transport protocols. It must be described how this works
with HTTP as well as other protocols typically used to transfer
Web content (e.g., RTP).</p></div><div class="div4">
<h5><a name="reqmt-compression" id="reqmt-compression"></a>3.1.1.14 CDF MUST NOT prevent compression of the data</h5><p>For efficiency, user agents and other renderers must support
served content that is compressed in whole or part.</p></div><div class="div4">
<h5><a name="reqmt-richmultimedia" id="reqmt-richmultimedia"></a>3.1.1.15 CDF MUST provide the ability for content developers to describe
or author rich media content</h5><p>Rich Multimedia Content is defined in <a href="#rich_multimedia_content_definition"><b>1.2 Definition of Rich Multimedia Content</b></a>.</p></div><div class="div4">
<h5><a name="reqmt-temporalsync" id="reqmt-temporalsync"></a>3.1.1.16
CDF MUST support temporal synchronization of dynamic content
coming from multiple references, possibly with multiple
references to the same source.</h5><p>Support the synchronization of multiple instances of
dynamic content, such as animations, audio and video, within a
single compound document.
</p></div><div class="div4">
<h5><a name="reqmt-crossnamespace-links" id="reqmt-crossnamespace-links"></a>3.1.1.17 CDF profiles MUST specify how focus traversal works with
compounding documents and languages.</h5><p>For example, when an XHTML document references an SVG document,
what is the relation between the XHTML document's focus traversal
and the SVG document's focus traversal. How does the SVG document
get focus and how does the focus traversal starts in the SVG
document? How does it end?
</p></div><div class="div4">
<h5><a name="reqmt-crossnamespace-animations" id="reqmt-crossnamespace-animations"></a>3.1.1.18 CDF profiles MUST specify triggering of animations across namespaces.</h5><p>For example, if an XHTML document references an SVG document,
the profile MUST specify how an SVG animation can be triggered by
an XHTML event target.</p></div><div class="div4">
<h5><a name="reqmt-accessibility" id="reqmt-accessibility"></a>3.1.1.19 CDF documents MUST cater for accessibility requirements</h5><p>All CDF profiles must take accessibility requirements in
consideration. The <a href="http://www.w3.org/WAI/">Web
Accessibility Initiative</a> has defined Web Accessibility
Guidelines, which must be used when CDF profiles are developed. In
addition, markup language specific accessibility guidelines have
been defined in Techniques for Web Content Accessibility
Guidelines document. A CDF profile must support all the techniques
that are supported by the markup language modules included in
it. The same applies for the authoring tool accessibility
guidelines and the user agent accessibility guidelines.</p></div><div class="div4">
<h5><a name="reqmt-dynamicupdating" id="reqmt-dynamicupdating"></a>3.1.1.20 CDF documents MUST support dynamic updating</h5><p>Dynamic documents and languages can be manipulated by scripts, etc. The user
interaction can fire events, which are caught by event
handlers. The event handlers can then manipulate the elements via
the DOM interface. These changes are then displayed to the
user. CDF markups must support dynamic updating across different
compounding markups.</p></div><div class="div4">
<h5><a name="reqmt-unified-key-handling-across-CD" id="reqmt-unified-key-handling-across-CD"></a>3.1.1.21 CDF MUST define the way soft-keys and accesskeys are handled across document and language components</h5><p>
For instance, what happens when there is a conflict between 2 accesskeys
which have the same value but are supposed to trigger different actions
in the parent and in the child documents.
</p></div><div class="div4">
<h5><a name="reqmt-fonts" id="reqmt-fonts"></a>3.1.1.22 CDR User Agents MUST provide a default font for use by all components</h5><p>Standalone components or renderers, such as SVGT engines, do not
always provide a default system font.</p><p>A CDR User Agent, however, must at least provide one default system
font to all components, such as browsers, SVG engines and other renderers.</p><p>The CDR specification cannot mandate any particular font, nor font
technology. But it mandates the availability of 'a' default font, so
that content providers can print text in any component or render as
simply as this can be done in XHTML.</p><p>The default system font may be bitmap based, antialiased or a
vector font. Ideally, the same default system font should be used for
all components.</p>
<h5><a name="code-reqmt-fonts" id="code-reqmt-fonts"></a>The following SVG sample markup MUST generate visible text.</h5><table class="scrap" summary="Scrap"><tbody><tr><td><pre><svg ...>
<text x="20" y="20" font-size="normal" fill="#000">Sample Text</text>
</svg></pre></td></tr></tbody></table></div><div class="div4">
<h5><a name="reqmt-serversideadaptation" id="reqmt-serversideadaptation"></a>3.1.1.23 CDF MUST NOT prevent server-side adaptation</h5><p>Some animations could be too heavy for some terminals - or
could be too 'unsophisticated' for others.</p><p>Server side adaptation must therefore be possible in order to
support less capable devices. For example, it should be possible
for a server to determine the SVG capabilities of the device (such
as the rendering and animation capabilities.</p></div><div class="div4">
<h5><a name="reqmt-limitedbandwidth" id="reqmt-limitedbandwidth"></a>3.1.1.24 CDF MUST support limited bandwidth networks and limited
capability devices</h5><p>Small footprint and mobile devices often are connected to
mobile networks, characterized by comparatively low bandwidth
and/or high connection latency. Additionally, mobile networks may
charge users for data downloaded. It is therefore desirable to
ensure that this bandwidth is used optimally.</p><p>Authoring tools and/or systems serving CDF documents must be
able to use techniques to reduce size of materials transmitted and
the latency involved.
</p></div></div><div class="div3">
<h4><a name="reqmt_cdr_ref" id="reqmt_cdr_ref"></a>3.1.2 CDR Framework</h4><p>These are requirements for a framework for Compound Document Formats
by Reference (CDR).</p><div class="div4">
<h5><a name="reqmt-cdr-inherit" id="reqmt-cdr-inherit"></a>3.1.2.1 CDR Framework MUST also support General CDF Framework requirements</h5><p>This framework inherits the requirements for <a href="#requirements_cdr_general"><b>3.1.1 General Framework</b></a> and
adds the additional requirements in the following subsections.</p><p>The inherited conformance requirements (MUST, SHALL, SHOULD, etc) will
remain unchanged unless otherwise noted.</p></div><div class="div4">
<h5><a name="reqmt-otherformats" id="reqmt-otherformats"></a>3.1.2.2 Each CDR profile and version MUST specify, which formats can be referenced</h5><p>Each CDR profile has a root document and one or more
child documents. The CDR profile has to specify both the
root document and the possible child documents.</p></div><div class="div4">
<h5><a name="reqmt-elementused" id="reqmt-elementused"></a>3.1.2.3 CDR MUST specify, for each format, the element used to
reference other formats, if any.</h5><p>For example, the CDR
specification will specify that the XHTML <object> element is to
be used for formats included in XHTML, and will specify the
usage of this element to include other formats.</p><p>It may be necessary to transfer some parameters declaratively
to a child document. Each CDR profile MAY specify a list of pre-defined
parameters/values for the <object> element. For instance, for CDR WP1,
there could be these kind of parameters/values:</p>
<h5><a name="scrap-usecase-object-parameters" id="scrap-usecase-object-parameters"></a></h5><table class="scrap" summary="Scrap"><tbody><tr><td><pre>
<param name="Volume" value="50" />
<param name="Mute" value="false" />
<param name="amination" value="onfocusevent" />
</pre></td></tr></tbody></table></div><div class="div4">
<h5><a name="reqmt-scriptingbetweencomponents" id="reqmt-scriptingbetweencomponents"></a>3.1.2.4 CDR MUST explain how scripting interacts between components and the parent document</h5><p>CDR profile documents must explain what kind of access, if any,
scripts have between the parent and child documents and
vice-versa. Can a script in a child document access its parent's
DOM, and if so, how? Can a script in a parent document access a
child's DOM? If there is access, the mechanism must be described.</p></div><div class="div4">
<h5><a name="reqmt-crossnamespace-focus" id="reqmt-crossnamespace-focus"></a>3.1.2.5 CDR profiles MUST specify how event propagation works
across namespace boundaries.</h5><p>CDF profile documents must explain how, if at all, events get
propagated from parent to child documents and vice-versa. Do
events from a parent document get propagated to the children
documents? Do events from a child document get propagated to the
parent document?</p><p>For example, if an XHTML document references an SVG document,
what is the event propagation model when the user activates an SVG
element? Do events bubble from a child document to the referencing
parent document? Does event capture happen from the root of the
referenced document or does it happen from the root of the
referencing document? This event propagation model MUST be
consistent with the <a href="http://www.w3.org/TR/DOM-Level-3-Events">DOM Level 3 event
model</a>.
</p></div><div class="div4">
<h5><a name="reqmt-link-activation" id="reqmt-link-activation"></a>3.1.2.6 CDR profiles MUST specify how link activation work with
referenced document.</h5><p>A referenced object may be wrapped with a XHTML anchor.
A referenced object may contain it's own embedded links.
A referenced object may be wrapped with a XHTML anchor and
contain it's own embedded links.</p><p>In addition, a referenced object may draw it's own visual
feedback for focus activation and/or mouse-over.</p><p>CDR must specify all these cases, since they may require different
handling, depending on the type of user interaction: pointing device
or joystick operation.</p></div><div class="div4">
<h5><a name="reqmt-crossnamespace-fragmentIDs" id="reqmt-crossnamespace-fragmentIDs"></a>3.1.2.7 CDR MUST support fragment identifiers in cross-namespace
interaction</h5><p>In CDR, child documents within a parent document are referenced
with URI references. This URI reference must support also
so-called <a href="http://www.w3.org/TR/webarch/#fragid">fragment
identifiers</a>. Each fragment identifier is passed to the
component or plug-in that displays the child document, when the
documents are loaded. The handling of the fragment identifiers
depends on the MIME type of the child document.</p></div><div class="div4">
<h5><a name="reqmt-currentLoadingStatus" id="reqmt-currentLoadingStatus"></a>3.1.2.8 CDR Profiles SHOULD provide a way to know the current loading status of a
referenced component</h5><p>Sometimes, one or several medias are needed before the end-user can
interact with a RichMedia application : for instance, a list of small
audio clips must be downloaded in an interactive game before the
end-user can start playing. Or some small audio clips must be downloaded
before the application can provide speech instructions in a navigation
system ("turn left", "turn right", ...). As a result, CDR should explain
a way to know whether a referenced component is currently loading, has
successfully been loaded or failed to be loaded and launch appropriate
actions accordingly.</p></div><div class="div4">
<h5><a name="reqmt-packaging-static" id="reqmt-packaging-static"></a>3.1.2.9 CDR MUST provide a solution for packaging of self-contained, static content</h5><p>Packaging is needed in order to support optimization of the
number of individual fetch operations that are required to
construct the final user experience on the device.</p></div><div class="div4">
<h5><a name="reqmt-packaging-streamed" id="reqmt-packaging-streamed"></a>3.1.2.10 CDR MAY provide a solution for packaging of streamed content</h5><p>In addition to <a href="#reqmt-packaging-static"><b>3.1.2.9 CDR MUST provide a solution for packaging of self-contained, static content</b></a>,
packaging of streams may be studied in order to accomodate audio
and video content.</p></div></div><div class="div3">
<h4><a name="reqmt_cdr_incl" id="reqmt_cdr_incl"></a>3.1.3 CDI Framework</h4><p>These are requirements for a framework for Compound Document Formats
by Inclusion (CDR).</p><div class="div4">
<h5><a name="reqmt-cdi-inherit" id="reqmt-cdi-inherit"></a>3.1.3.1 CDI Framework MUST also support General Framework requirements</h5><p>This framework inherits the requirements for <a href="#requirements_cdr_general"><b>3.1.1 General Framework</b></a>
and adds the additional requirements in the following subsections.</p><p>The inherited conformance requirements (MUST, SHALL, SHOULD, etc) will
remain unchanged unless otherwise noted.</p></div><div class="div4">
<h5><a name="reqmt_fwk_cdi_ns_dispatch" id="reqmt_fwk_cdi_ns_dispatch"></a>3.1.3.2 CDI compliant applications MUST support namespace-based dispatching</h5><p>CDI applications MUST support a framework for namespace-based
dispatching of component languages within compound documents. User
agents must be able to register for a specific namespace and be invoked
when nodes from the associated component language are encountered.</p></div><div class="div4">
<h5><a name="reqmt_fwk_cdi_dom_apis" id="reqmt_fwk_cdi_dom_apis"></a>3.1.3.3 CDI Profiles MUST define which DOM interfaces are implemented</h5><p>A CDI Profile must define which DOM interfaces are implemented by the
document object representing the document. Component languages may have
their on specialized DOM interfaces based on associated MIME types or
namespace. For example, HTML and SVG have specialized DOM interfaces.</p></div><div class="div4">
<h5><a name="reqmt_fwk_cdi_imported_dom_apis" id="reqmt_fwk_cdi_imported_dom_apis"></a>3.1.3.4 CDI Profiles MUST define DOM interfaces behavior
when nodes are imported into another component language</h5><p>CDI Profiles must define what happens to DOM interfaces
when nodes are imported into another namespace. For example, do the
XForms elements imported into the XHTML2 namespace implement the
HTMLElement interface (or equivalent for XHTML2)?</p></div><div class="div4">
<h5><a name="reqmt_fwk_cdi_validation" id="reqmt_fwk_cdi_validation"></a>3.1.3.5 CDI Profiles MUST provide a schema for validating mixed component language documents</h5><p>Schemas must define which nodes are validate and invalid based on rules
defined in the profile. This schema can be used to validate content.</p><p>It would be desirable to reuse existing schemas by referencing them and
placing inclusion rules in a profile schema.</p></div><table border="1" bgcolor="yellow" summary="ToDo: Framework reqs for CDI" id="todo-req-fmwk-cdi"><tr><td align="left" valign="top"><b>ToDo</b></td><td align="right" valign="top">Framework reqs for CDI</td></tr><tr><td align="left" valign="top"><b>Owner</b></td><td align="right" valign="top">Steve Speicher</td></tr><tr><td align="left" valign="top"><b>Note</b></td><td align="right" valign="top"></td></tr><tr><td align="left" valign="top"><b>Links</b></td><td align="right" valign="top"></td></tr></table></div></div><div class="div2">
<h3><a name="high_level_rich_multimedia_content_requirements" id="high_level_rich_multimedia_content_requirements"></a>3.2 WICD Core</h3><p>The language profile combining XHTML, CSS and SVG according to the
CDF rules is referred to in this document as High-level Requirements for
Rich Multimedia Content. This
section identifies the requirements specific for the use of XHTML as
the <font color="red"><dfn>parent document</dfn></font> and SVG Tiny as the <font color="red"><dfn>child
document</dfn></font>. This profile supports presentation of rich multimedia
content, as defined in <a href="#rich_multimedia_content_definition"><b>1.2 Definition of Rich Multimedia Content</b></a>, and many of the
requirements herein are related to this definition. XHTML, CSS and SVG
have been chosen as the basis of Rich Multimedia Content according to analysis
of existing specifications and their applicability to rich
multimedia content: <a href="#relationships-with-other"><b>1.3 Relationships With Other Technologies</b></a></p><p>These requirements should be considered as additional
requirements to the applicable requirements specified in other
sections of the document.</p><div class="div3">
<h4><a name="reqmt-wicd-core-general" id="reqmt-wicd-core-general"></a>3.2.1 General WICD Core</h4><p>These are general WICD requirements that apply to both
compounding by reference (CDR) or inclusion (CDI).</p><div class="div4">
<h5><a name="reqmt-wicd-core-inherit" id="reqmt-wicd-core-inherit"></a>3.2.1.1 WICD Profiles MUST also support General Framework requirements</h5><p>General WICD Core inherits the requirements for <a href="#requirements_cdr_general"><b>3.1.1 General Framework</b></a>
and adds the additional requirements in the following subsections.</p><p>The inherited conformance requirements (MUST, SHALL, SHOULD, etc) will
remain unchanged unless otherwise noted.</p></div><div class="div4">
<h5><a name="reqmt-userinteractionmodel" id="reqmt-userinteractionmodel"></a>3.2.1.2 WICD Profiles MUST specify a user interaction model</h5><p>WICD Profiles must support a clear user interaction model between
components (event/focus management). Interactivity between
components will help to provide a seamless and compelling user
experience of documents which combine XHTML and media
elements.
</p></div><div class="div4">
<h5><a name="reqmt-scalablegraphics" id="reqmt-scalablegraphics"></a>3.2.1.3 WICD Profiles MUST support 2D scalable vector graphics</h5><p>
2D Scalable vector graphics are required in order to easily deploy the
same user interface onto multiple devices with different screen
sizes / shapes and resolutions.
</p></div><div class="div4">
<h5><a name="reqmt-audio" id="reqmt-audio"></a>3.2.1.4 WICD Profiles MUST support audio</h5><p>User agents must support the ability to play audio while rendering content. For example, a rendered document may choose to play music while the document is displayed.</p></div><div class="div4">
<h5><a name="reqmt-video" id="reqmt-video"></a>3.2.1.5 WICD Profiles SHOULD support video</h5><p>User agents should support the ability to play video while rendering content. For example, a rendered document may choose to play a video clip while the document is displayed.</p></div><div class="div4">
<h5><a name="reqmt-layouts" id="reqmt-layouts"></a>3.2.1.6 WICD Profiles MUST support grid, flow, overlapping layouts</h5><p>In order to create rich content document, content authors need the
ability to position and layout information items or user interface
components. This is crucial authoring feature which also allows content
to adapt to different screen sizes and aspect ratio. Layout is a
complement to the scalable nature to formats such as SVG. In WICD Profiles
, grid and flow layouts MUST be supported. Overlapping layout, i.e.,
the ability to layout component that overlap completely or partially,
MUST also be supported.</p></div><div class="div4">
<h5><a name="reqmt-XHTMLasroot" id="reqmt-XHTMLasroot"></a>3.2.1.7 WICD Profiles MUST support XHTML as a root/host language</h5><p>However it is not necessarily the only root hosting language.</p></div><div class="div4">
<h5><a name="reqmt-animatedSVGicons" id="reqmt-animatedSVGicons"></a>3.2.1.8 WICD Profiles MUST define for animated SVG icons to act like HTML
images (no need for interactivity, links, zoom and pan)</h5><p>
When used as background images, it is complex and most often irrelevant to
provide interaction, such as zooming, panning, linking and mouse events
processing, with the SVG graphics. However, animation makes senses in that
it can provide decorative value.
</p></div><div class="div4">
<h5><a name="reqmt-focusevents" id="reqmt-focusevents"></a>3.2.1.9 WICD Profiles MUST define a way for events to trigger SVG
animation</h5><p>This is required in order to support pleasing
button animation on select and activate events, such as focus
events, beyond the current "on/off" capability in
CSS</p></div><div class="div4">
<h5><a name="reqmt-realestatenegotiation" id="reqmt-realestatenegotiation"></a>3.2.1.10 WICD Profiles MUST define the process for real-estate negotiation
between an XHTML document and a referenced SVG document</h5><p>WICD Profiles will provide comprehensive, mandatory rules that
specify how document components from different XML vocabularies are
scaled when they occur within other components
(right-sizing). Support the ability for relative size measures
to be used by authors. Ensure that rules define the behavior
when fixed and relative sized components are used together
within a single document. Ensure that the rules define the
behavior associated with areas of the containing component
not filled by the contained component. Thus, it will be
possible to create truly screen size-independent content.
</p></div><div class="div4">
<h5><a name="reqmt-leftovers" id="reqmt-leftovers"></a>3.2.1.11 WICD Profiles MUST define handling of leftover SVG area</h5><p>Rendering SVG content in a fixed-sized area often
results in visible areas outside of the SVG viewbox. How these areas
are filled must be defined.</p></div><div class="div4">
<h5><a name="reqmt-systemfontsupport" id="reqmt-systemfontsupport"></a>3.2.1.12 WICD Profiles MUST define system font support in SVG</h5><p>SVGT does not mandate system fonts, but in the context of a
user agent, highly optimized system fonts are available. On many
devices (when executed in the context of a user agent), highly
optimized fonts are available. </p><p>It is therefore necessary to make highly optimized terminal
fonts (used by the user agent) available to SVG as system fonts and
to support the ability for common font sets to be used
throughout the combined document. In particular, platform fonts
should be able to be used if supported, with support font fall-back
mechanisms to provide defaults in the event that chosen fonts
are unavailable. The SVG <text> element should always display
something as long as it is within the viewport.</p><p>Related to CDR requirement: <a href="#reqmt-fonts"><b>3.1.1.22 CDR User Agents MUST provide a default font for use by all components</b></a>.</p></div><div class="div4">
<h5><a name="reqmt-unifiedrendering" id="reqmt-unifiedrendering"></a>3.2.1.13 WICD Profiles MUST support a unified rendering and processing model</h5><p>Ensure that rendering is consistent across all components of a
WICD Profile document. In particular, ensure that there are suitable
rules that define how z-ordering applies between different
components which may overlay one another. Also ensure that there
are rules that define how transparency is handled when components
overlay one another. CSS z-ordering may provide a mechanism for
controlling this.</p></div><div class="div4">
<h5><a name="reqmt-transparency" id="reqmt-transparency"></a>3.2.1.14 WICD Profiles MUST support SVG backgrounds</h5><p>A WICD user agent MUST support static SVG background images and
MAY support animated or scripted SVG background images. Authors
however should not assume that the latter functionality will be
available.
</p></div><div class="div4">
<h5><a name="reqmt-transparency2" id="reqmt-transparency2"></a>3.2.1.15 WICD Profiles MAY support XHTML backgrounds</h5><p>A WICD user agent MAY support compositing above an XHTML document defined as a background image.
</p></div><div class="div4">
<h5><a name="reqmt-scalablediagrams" id="reqmt-scalablediagrams"></a>3.2.1.16 WICD Profiles MUST support scalable diagrams that can be animated
and can cause link traversal</h5><p>An example of usage is the implementation of buttons which render
their own visual feedback (animated buttons for
navigation). These will provide a scalable alternative to the
use of images as the source of links that can be
traversed. These should be allowed to contain animation, but
not rich interaction.
</p></div><div class="div4">
<h5><a name="reqmt-temportal-start-and-stop" id="reqmt-temportal-start-and-stop"></a>3.2.1.17 WICD Profiles SHOULD provide temporal synchronization with dynamic media</h5><p>The Profile should be able to synchronize events with the start and end of playback of dynamic media objects, such as a video or audio stream.</p></div><div class="div4">
<h5><a name="reqmt-stop-and-start-media" id="reqmt-stop-and-start-media"></a>3.2.1.18 WICD Profiles MAY provide functionality to stop and start media objects</h5><p>The Profile may include mechanisms to start playback of dynamic content (from the start of a stream) and to stop playback (with automatic rewind).</p></div></div><div class="div3">
<h4><a name="reqmt-wicd-core-ref" id="reqmt-wicd-core-ref"></a>3.2.2 CDR WICD Core</h4><p>These are CDR WICD requirements that apply to compounding by reference.</p><div class="div4">
<h5><a name="reqmt-wicd-core-cdr-inherit" id="reqmt-wicd-core-cdr-inherit"></a>3.2.2.1 CDR WICD Profiles MUST also support CDR Framework requirements</h5><p>CDR WICD Profiles inherits the requirements for <a href="#reqmt_cdr_ref"><b>3.1.2 CDR Framework</b></a>
and adds the additional requirements in the following subsections.</p><p>The inherited conformance requirements (MUST, SHALL, SHOULD, etc) will
remain unchanged unless otherwise noted.</p></div><div class="div4">
<h5><a name="reqmt-xhtmlplussvg" id="reqmt-xhtmlplussvg"></a>3.2.2.2 CDR Profile 1 MUST define how to reference SVG graphics and resources
from an XHTML document</h5><p>A compound document by reference is defined as one root or
parent document that makes a reference to separate child
documents. Compound Document profiles that include SVG Tiny or Full as
referenced documents from XHTML must define how to reference the
separate SVG graphics and resources.</p></div><div class="div4">
<h5><a name="reqmt-XHTMLobjectelement" id="reqmt-XHTMLobjectelement"></a>3.2.2.3 The XHTML <object> element MUST be used for referring to
other formats from XHTML</h5><p>It is desirable to achieve the goal of embedding media and
other objects into XHTML documents by using the existing
<object> element rather than extending XHTML. The XHTML
<object> element will be the method by which XML document types
will be referenced from XHTML documents.
</p></div><div class="div4">
<h5><a name="reqmt-xhtmlsvginteractionmodel" id="reqmt-xhtmlsvginteractionmodel"></a>3.2.2.4 CDR Profile 1 MUST define the interaction model for an SVG
document referenced by an XHTML document</h5><p>To ensure interoperability, it is important that the CDR Profile 1
specification defines the interaction model for SVG documents referenced
by XHTML documents. For example, the interaction model must define if
and how interaction with an SVG document requires activation, or if
activation is optional, how activation is controlled. By the same token,
the interaction model should define the precedence rules between the SVG
content and the referencing XHTML document, for example regarding
hyperlinking: if an XHTML <object> is enclosed in an <a> element and the
<object> references an SVG document which itself displays anchors, what
is the behavior when clicking over one of the anchors in the SVG element?</p><p>See also <a href="#reqmt-userinteractionmodel"><b>3.2.1.2 WICD Profiles MUST specify a user interaction model</b></a></p></div><div class="div4">
<h5><a name="reqmt-animationOnLoad" id="reqmt-animationOnLoad"></a>3.2.2.5 CDR Profile 1 SHOULD provide a way to play an animation while some
referenced components of the Combined Document are loading</h5><p>The profile should define mechanisms allowing to play an animation while
one or several parts of the combined document are loading. For instance,
this can be a progress bar informing the end-user about the loading
progress or an advertising which plays while some audio/video content is
being fetched.</p></div><div class="div4">
<h5><a name="reqmt-audiomixing" id="reqmt-audiomixing"></a>3.2.2.6 CDR Profile 1 MUST specify the behavior of audio mixing</h5><p>CDR Profile 1 must specify how user agents behave when multiple
audio streams are played simultaneously within a compound
document.</p></div></div><div class="div3"><p>These are CDR WICD requirements that apply to compounding by inclusion.</p><div class="div4">
<h5><a name="reqmt-wicd-core-cdi-inherit" id="reqmt-wicd-core-cdi-inherit"></a>3.2.3.1 CDI WICD Profiles MUST also support CDI Framework requirements</h5><p>CDI WICD Profiles inherit the requirements for
<a href="http://www.w3.org/TR/CDRReqs/">Compound Document by Reference Use Cases and Requirements 1.0</a>
and adds the additional requirements in the following subsections.</p><p>The inherited conformance requirements (MUST, SHALL, SHOULD, etc) will
remain unchanged unless otherwise noted.</p></div><div class="div4">
<h5><a name="reqmt_fwk_cdi_view_modes" id="reqmt_fwk_cdi_view_modes"></a>3.2.3.2 A CDI WICD Profile MUST define a common vocabulary of view modes that is
sufficient to describe the behaviors of existing document format
specifications.</h5><p>This document will call these different types of behavior (and the
default behavior of interpreting and presenting the content) modes. The
framework must define a common vocabulary of modes that is sufficient to
describe the behaviors of existing document format specifications.
Document format specifications (or, for existing document formats,
perhaps the framework specification) must define how their elements
behave in each mode.</p><p>For example, SVG says that elements not in the SVG namespace should
be ignored unless they are inside of svg:foreignObject, HTML says that
elements inside an html:object element that loaded successfully or a
html:noframes element in a user agent that supports frames should be
ignored, and the 'none' value of the CSS 'display' property can cause a
subtree not to appear in the presentation.</p></div><div class="div4">
<h5><a name="reqmt_fwk_cdi_layout" id="reqmt_fwk_cdi_layout"></a>3.2.3.3 CDI WICD Core MUST define layout semantics across elements from varying namespace boundaries</h5><p>CDI WICD Profiles must describe layout behavior in a way that is
meaningful when various component languages interact. CDF may define
a vocabulary that specifications can use to describe the information
that layout algorithms need from or provide to parent or child objects
in another document format. Examples of parameters that parent
elements need to provide to child elements are width and height.
Examples of parameters that child elements need to provide to parent
elements are desired height given a width input (or vice versa, for a
horizontal block progression), preferred and minimum intrinsic sizes
(in one dimension or two, possibly with additional information on the
relationship between the dimensions when given in two dimensions).
In all of these cases, it needs to be specified whether the information
described already includes information from things like the CSS
'width', 'min-width', and 'max-width' properties or whether such
properties need to be considered by the recipient of the information.
</p></div>
<h4><a name="reqmt-wicd-core-incl" id="reqmt-wicd-core-incl"></a>3.2.3 CDI WICD Core</h4><table border="1" bgcolor="yellow" summary="ToDo: WICD Core CDI reqs" id="todo-core-incl"><tr><td align="left" valign="top"><b>ToDo</b></td><td align="right" valign="top">WICD Core CDI reqs</td></tr><tr><td align="left" valign="top"><b>Owner</b></td><td align="right" valign="top">Steve Speicher</td></tr><tr><td align="left" valign="top"><b>Note</b></td><td align="right" valign="top"></td></tr><tr><td align="left" valign="top"><b>Links</b></td><td align="right" valign="top"></td></tr></table></div></div><div class="div2">
<h3><a name="rich_multimedia_content_requirements" id="rich_multimedia_content_requirements"></a>3.3 CDR WICD Profile 1</h3><p>The language profile combining XHTML, CSS and SVG according to the
CDR rules is referred to in this document as CDR Profile 1. This
section identifies the requirements specific for the use of XHTML as
the parent CDR Profile 1 document and SVG Tiny as the child
document. This profile supports presentation of rich multimedia
content, as defined in <a href="#rich_multimedia_content_definition"><b>1.2 Definition of Rich Multimedia Content</b></a>, and many of the
requirements herein are related to this definition. XHTML and SVG
have been chosen as the first profile for CDR according to analysis
of existing specifications and their applicability to rich
multimedia content: <a href="#relationships-with-other"><b>1.3 Relationships With Other Technologies</b></a></p><p>These requirements should be considered as additional
requirements to the applicable requirements specified in other
sections of the document.</p><div class="div3">
<h4><a name="reqmt-wicd-prof1-mobile" id="reqmt-wicd-prof1-mobile"></a>3.3.1 CDR WICD Profile 1 - Mobile</h4><p>The profile requirements are intended to support constrained devices
which may require subset profiles of existing specifications to be required.</p><div class="div4">
<h5><a name="reqmt-p1-wicd" id="reqmt-p1-wicd"></a>3.3.1.1 CDR WICD Profile 1 - Mobile MUST also support CDR WICD Core requirements</h5><p>This profile inherits the requirements for <a href="#reqmt-wicd-core-ref"><b>3.2.2 CDR WICD Core</b></a> and
adds the additional requirements in the following subsections.</p><p>The inherited conformance requirements (MUST, SHALL, SHOULD, etc) will
remain unchanged unless otherwise noted.</p></div></div><div class="div3">
<h4><a name="reqmt-wicd-prof1-full" id="reqmt-wicd-prof1-full"></a>3.3.2 CDR WICD Profile 1 - Full</h4><p>The profile requirements are intended to support non-constrained devices
which should require full profiles of existing specifications to be required.</p><div class="div4">
<h5><a name="reqmt-p1-wicd-full-inherit" id="reqmt-p1-wicd-full-inherit"></a>3.3.2.1 CDR Profile 1 - Full MUST also support CDR WICD Core requirements</h5><p>This profile inherits the requirements for <a href="#reqmt-wicd-core-ref"><b>3.2.2 CDR WICD Core</b></a> and
adds the additional requirements in the following subsections.</p><p>The inherited conformance requirements (MUST, SHALL, SHOULD, etc) will
remain unchanged unless otherwise noted.</p></div></div></div><div class="div2">
<h3><a name="rich_multimedia_content_requirements_prof2" id="rich_multimedia_content_requirements_prof2"></a>3.4 CDI & CDR WICD Profile 2</h3><p>This profile addresses combining languages by reference and inclusions, as well
as requirements for form processing and cross-namespace eventing.</p><table border="1" bgcolor="yellow" summary="ToDo: Determine content for CDI Profile 2" id="todo.req-prof2-content"><tr><td align="left" valign="top"><b>ToDo</b></td><td align="right" valign="top">Determine content for CDI Profile 2</td></tr><tr><td align="left" valign="top"><b>Owner</b></td><td align="right" valign="top">Steve Speicher</td></tr><tr><td align="left" valign="top"><b>Note</b></td><td align="right" valign="top"></td></tr><tr><td align="left" valign="top"><b>Links</b></td><td align="right" valign="top"></td></tr></table><div class="div3">
<h4><a name="reqmt-wicd-prof2-mobile" id="reqmt-wicd-prof2-mobile"></a>3.4.1 CDI WICD Profile 2 - Mobile</h4><p>The profile requirements are intended to support constrained devices
which may require subset profiles of existing specifications to be required.</p><div class="div4">
<h5><a name="reqmt-p2-profile1" id="reqmt-p2-profile1"></a>3.4.1.1 CDR & CDI Profile 2 - Mobile MUST also support CDI WICD Core and CDR WICD Profile 1 - Mobile Requirements</h5><p>This profile inherits the requirements for <a href="#reqmt-p1-wicd"><b>3.3.1.1 CDR WICD Profile 1 - Mobile MUST also support CDR WICD Core requirements</b></a>
and <a href="#reqmt-wicd-core-incl"><b>3.2.3 CDI WICD Core</b></a>. It adds any additional
requirements in the following subsections.</p><p>The inherited conformance requirements(MUST, SHALL, SHOULD, etc) will
remain unchanged unless otherwise noted.</p></div><div class="div4">
<h5><a name="reqmt-p2-svg" id="reqmt-p2-svg"></a>3.4.1.2 CDR & CDI Profile 2 MUST support SVG as a child language of XHTML</h5><p>CDR & CDI Profile 2 specification must define the interaction
model for SVG language contructs integrated in the XHTML parent language.</p><p>See related requirement <a href="#reqmt-xhtmlsvginteractionmodel"><b>3.2.2.4 CDR Profile 1 MUST define the interaction model for an SVG
document referenced by an XHTML document</b></a>. </p></div><div class="div4">
<h5><a name="reqmt-p2-xforms" id="reqmt-p2-xforms"></a>3.4.1.3 CDR & CDI Profile 2 MUST support XForms as a child language of XHTML</h5><p>CDR & CDI Profile 2 specification must define the interaction
model for XForms language contructs integrated in the XHTML parent language.
For example, the interaction model must define that an XForm's <input>
element is valid within an XHTML <p> and how styling and eventing
flow across namespace boundaries languages.</p><p>This includes having XHTML defining the <id> attribute for XForms
<model> and <instance> elements for identification needed
for references.</p></div><div class="div4">
<h5><a name="reqmt-p2-xforms-svg" id="reqmt-p2-xforms-svg"></a>3.4.1.4 CDR & CDI Profile 2 MUST support SVG as a child language of XForms</h5><p>CDR & CDI Profile 2 specification must define the interaction
model for SVG contructs referenced or included in the XForms parent
document or language.</p></div></div><div class="div3">
<h4><a name="reqmt-wicd-prof2-full" id="reqmt-wicd-prof2-full"></a>3.4.2 CDI WICD Profile 2 - Full</h4><p>The profile requirements are intended to support non-constrained devices
which should require full profiles of existing specifications to be required.</p><div class="div4">
<h5><a name="reqmt-p2-wicd-full-inherit" id="reqmt-p2-wicd-full-inherit"></a>3.4.2.1 CDI Profile 2 - Full MUST also support CDI Profile 2 - Mobile requirements</h5><p>This profile inherits the requirements for <a href="#reqmt-wicd-prof2-mobile"><b>3.4.1 CDI WICD Profile 2 - Mobile</b></a> and
adds the additional requirements in the following subsections.</p><p>The inherited conformance requirements (MUST, SHALL, SHOULD, etc) will
remain unchanged unless otherwise noted.</p></div></div><table border="1" bgcolor="yellow" summary="ToDo: Complete the list of Profile 2 requirements" id="todo.reqmt-p2-xforms-svg"><tr><td align="left" valign="top"><b>ToDo</b></td><td align="right" valign="top">Complete the list of Profile 2 requirements</td></tr><tr><td align="left" valign="top"><b>Owner</b></td><td align="right" valign="top">Need Help</td></tr><tr><td align="left" valign="top"><b>Note</b></td><td align="right" valign="top">I'm trying to keep WICD to be XHTML, SVG, CSS, DOM. The Profile 2
adds 2 things: 1) by inclusion 2) new languagues (XForms) for inclusion.
Seems like we could have a revision of WICD to include XForms or just leave
in Profile 2 section.
</td></tr><tr><td align="left" valign="top"><b>Links</b></td><td align="right" valign="top"></td></tr></table></div></div></div><div class="back"><div class="div1">
<h2><a name="references" id="references"></a>A References (Non-Normative)</h2><table border="1" bgcolor="yellow" summary="ToDo: Update references" id="todo.refs"><tr><td align="left" valign="top"><b>ToDo</b></td><td align="right" valign="top">Update references</td></tr><tr><td align="left" valign="top"><b>Owner</b></td><td align="right" valign="top">Steve Speicher</td></tr><tr><td align="left" valign="top"><b>Note</b></td><td align="right" valign="top">
Sync with what latest specs references. Trying to use tool to gen but it doesn't emit XMLSpec, sent a note to Dominique.
</td></tr><tr><td align="left" valign="top"><b>Links</b></td><td align="right" valign="top">
<a href="http://www.w3.org/2002/01/tr-automation/tr-biblio">Stylesheet to format bibliographic data for our TR publications</a>
</td></tr></table><dl><dt class="label"><a name="xml-stylesheet" id="xml-stylesheet"></a>Associating Style Sheets with XML documents</dt><dd>
<a href="http://www.w3.org/TR/xml-stylesheet"><cite>
Associating Style Sheets with XML documents
</cite></a>
, James Clark, Editor. World Wide Web Consortium, 29 Jun 1999.
This version is
http://www.w3.org/1999/06/REC-xml-stylesheet-19990629. The
<a href="http://www.w3.org/TR/xml-stylesheet">latest version</a>
is available at http://www.w3.org/TR/xml-stylesheet.
</dd><dt class="label"><a name="REC-MathML" id="REC-MathML"></a>Mathematical Markup Language (MathML) 1.01 Specification</dt><dd>
<a href="http://www.w3.org/TR/REC-MathML"><cite>
Mathematical Markup Language (MathML) 1.01 Specification
</cite></a>
, Patrick Ion and Robert Miner, Editors. World Wide Web
Consortium, 07 Jul 1999. This version is
http://www.w3.org/1999/07/REC-MathML-19990707. The
<a href="http://www.w3.org/TR/REC-MathML">latest version</a>
is available at http://www.w3.org/TR/REC-MathML.
</dd><dt class="label"><a name="REC-CSS2" id="REC-CSS2"></a>Cascading Style Sheets, level 2 (CSS2) Specification</dt><dd>
<a href="http://www.w3.org/TR/REC-CSS2"><cite>
Cascading Style Sheets, level 2 (CSS2) Specification
</cite></a>
, Chris Lilley, Håkon Wium Lie, Bert Bos, and Ian Jacobs,
Editors. World Wide Web Consortium, 12 May 1998. This version is
http://www.w3.org/TR/1998/REC-CSS2-19980512. The
<a href="http://www.w3.org/TR/REC-CSS2">latest version</a>
is available at http://www.w3.org/TR/REC-CSS2.
</dd><dt class="label"><a name="CSS-MOBILE" id="CSS-MOBILE"></a>CSS-MOBILE</dt><dd>
<a href="http://www.w3.org/TR/2002/CR-css-mobile-20020725"><cite>
CSS Mobile Profile 1.0
</cite></a>
, D. Dominiak, T. Wugofski, T. Roy, P. Stark, Editors, W3C Candidate
Recommendation (work in progress), 25 July 2002, http://www.w3.org/TR/2002/CR-css-mobile-20020725.
Latest version available at http://www.w3.org/TR/css-mobile .
</dd></dl></div><div class="div1">
<h2><a name="acknowledgements" id="acknowledgements"></a>B Acknowledgements (Non-Normative)</h2><p>The editors would like to thank the contributors:</p><blockquote><p>Daniel Appelquist (Previous Editor), Vodafone Group Services Limited<br />Jon Ferraiolo, Adobe<br />Vincent Hardy (Previous Working Group Chair), Sun Microsystems<br />Scott Hayman, RIM<br />Dean Jackson (Working Group Team Contact), W3C<br />Kevin Kelly (Working Group Chair), IBM<br />Timur Mehrvarz (Previous Editor), Vodafone Group Services Limited<br />Lasse Pajunen, Nokia<br />Antoine Quint (Previous Editor), Fuchsia Design (Invited Expert)<br />Peter Stark, Sony Ericsson</p></blockquote></div><div class="div1">
<h2><a name="changes-log" id="changes-log"></a>C Changes Log (Non-Normative)</h2><ul><li><p>20051129</p><ul><li><p>Added requirements <a href="#reqmt-cdr-inherit"><b>3.1.2.1 CDR Framework MUST also support General CDF Framework requirements</b></a>,
<a href="#reqmt-cdi-inherit"><b>3.1.3.1 CDI Framework MUST also support General Framework requirements</b></a>, <a href="#reqmt-wicd-core-inherit"><b>3.2.1.1 WICD Profiles MUST also support General Framework requirements</b></a>,
<a href="#reqmt-wicd-core-cdr-inherit"><b>3.2.2.1 CDR WICD Profiles MUST also support CDR Framework requirements</b></a>,
<a href="#reqmt-wicd-core-cdi-inherit"><b>3.2.3.1 CDI WICD Profiles MUST also support CDI Framework requirements</b></a>,
<a href="#reqmt-p1-wicd-full-inherit"><b>3.3.2.1 CDR Profile 1 - Full MUST also support CDR WICD Core requirements</b></a>,
<a href="#reqmt-p2-wicd-full-inherit"><b>3.4.2.1 CDI Profile 2 - Full MUST also support CDI Profile 2 - Mobile requirements</b></a>,
<a href="#reqmt_fwk_cdi_validation"><b>3.1.3.5 CDI Profiles MUST provide a schema for validating mixed component language documents</b></a>
(SS)</p></li><li><p>Removing requirement "CDR & CDI Profile 2 MUST define
how a User Agent is able to identify a CDR & CDI Profile 2
document" as its covered by Framework requirements. (SS) </p></li></ul></li><li><p>20051122</p><ul><li><p>Added sections <a href="#reqmt_cdr_ref"><b>3.1.2 CDR Framework</b></a>, <a href="#reqmt_cdr_incl"><b>3.1.3 CDI Framework</b></a>,
<a href="#reqmt-wicd-core-general"><b>3.2.1 General WICD Core</b></a>, <a href="#reqmt-wicd-core-ref"><b>3.2.2 CDR WICD Core</b></a>,
<a href="#reqmt-wicd-core-incl"><b>3.2.3 CDI WICD Core</b></a>, <a href="#reqmt-wicd-prof1-mobile"><b>3.3.1 CDR WICD Profile 1 - Mobile</b></a>,
<a href="#reqmt-wicd-prof1-full"><b>3.3.2 CDR WICD Profile 1 - Full</b></a>, <a href="#reqmt-wicd-prof2-mobile"><b>3.4.1 CDI WICD Profile 2 - Mobile</b></a> and <a href="#reqmt-wicd-prof2-full"><b>3.4.2 CDI WICD Profile 2 - Full</b></a>
and reassigned requirements to appropriate new sections. (SS) </p></li></ul></li><li><p>20051120</p><ul><li><p>Added sections <a href="#requirements_cdr"><b>3.1 Framework</b></a>, <a href="#requirements_cdr_general"><b>3.1.1 General Framework</b></a>
and reassigned requirements to appropriate new sections. (SS) </p></li></ul></li><li><p>20051115</p><ul><li><p>Added definition WICD to <a href="#rich_multimedia_content_definition"><b>1.2 Definition of Rich Multimedia Content</b></a> (SS) </p></li><li><p>Updated description in <a href="#reqmt-p2-xforms"><b>3.4.1.3 CDR & CDI Profile 2 MUST support XForms as a child language of XHTML</b></a> (SS)</p></li><li><p>Added requirement <a href="#reqmt-p1-wicd"><b>3.3.1.1 CDR WICD Profile 1 - Mobile MUST also support CDR WICD Core requirements</b></a> (SS)</p></li><li><p>Added definitions for: <a href="#relationships-xmlid"><b>1.3.2 XML:id</b></a>,
<a href="#relationships-xmlevents"><b>1.3.5 XML Events</b></a>,
<a href="#relationships-css"><b>1.3.6 CSS</b></a>,
<a href="#relationships-dom"><b>1.3.7 DOM</b></a>,
<a href="#relationships-mathml"><b>1.3.9 MathML</b></a>,
<a href="#relationships-xbl"><b>1.3.12 XBL</b></a> (SS)
</p></li><li><p>Resolved terminology issues with CDI <a href="#terms"><b>1.4 Definition of Terms</b></a>(SS)</p></li></ul></li><li><p>20051109</p><ul><li><p>Added new section <a href="#high_level_rich_multimedia_content_requirements"><b>3.2 WICD Core</b></a> and relocated subsections:(SS)</p><ul><li><p><a href="#reqmt-userinteractionmodel"><b>3.2.1.2 WICD Profiles MUST specify a user interaction model</b></a> </p></li><li><p><a href="#reqmt-scalablegraphics"><b>3.2.1.3 WICD Profiles MUST support 2D scalable vector graphics</b></a> </p></li><li><p><a href="#reqmt-audio"><b>3.2.1.4 WICD Profiles MUST support audio</b></a> </p></li><li><p><a href="#reqmt-video"><b>3.2.1.5 WICD Profiles SHOULD support video</b></a> </p></li><li><p><a href="#reqmt-layouts"><b>3.2.1.6 WICD Profiles MUST support grid, flow, overlapping layouts</b></a> </p></li><li><p><a href="#reqmt-XHTMLasroot"><b>3.2.1.7 WICD Profiles MUST support XHTML as a root/host language</b></a> </p></li><li><p><a href="#reqmt-animatedSVGicons"><b>3.2.1.8 WICD Profiles MUST define for animated SVG icons to act like HTML
images (no need for interactivity, links, zoom and pan)</b></a> </p></li><li><p><a href="#reqmt-focusevents"><b>3.2.1.9 WICD Profiles MUST define a way for events to trigger SVG
animation</b></a> </p></li><li><p><a href="#reqmt-realestatenegotiation"><b>3.2.1.10 WICD Profiles MUST define the process for real-estate negotiation
between an XHTML document and a referenced SVG document</b></a> </p></li><li><p><a href="#reqmt-leftovers"><b>3.2.1.11 WICD Profiles MUST define handling of leftover SVG area</b></a> </p></li><li><p><a href="#reqmt-systemfontsupport"><b>3.2.1.12 WICD Profiles MUST define system font support in SVG</b></a> </p></li><li><p><a href="#reqmt-unifiedrendering"><b>3.2.1.13 WICD Profiles MUST support a unified rendering and processing model</b></a> </p></li></ul></li><li><p>Moved these subsections into <a href="#requirements_cdr"><b>3.1 Framework</b></a> and adjusted text (SS)</p><ul><li><p><a href="#reqmt-useragentidentifies"><b>3.1.1.5 Each Profile MUST explain how a User Agent is able to identify it</b></a></p></li><li><p><a href="#reqmt-identificationofmarkup"><b>3.1.1.6 Each Profile MUST support identification of markup and versions in CDF documents</b></a></p></li><li><p><a href="#reqmt-advertisingsvg"><b>3.1.1.7 Each Profile MUST support advertising the specific supported versions
of formats and capabilities in headers</b></a> </p></li></ul></li><li><p>Changed SVGT to be SVG in <a href="#reqmt-xhtmlplussvg"><b>3.2.2.2 CDR Profile 1 MUST define how to reference SVG graphics and resources
from an XHTML document</b></a> (SS)</p></li></ul></li><li><p>20051102</p><ul><li><p>Miscellaneous grammatical updates (SS)</p></li><li><p>Removed the change log entries from previous revision, link provided (SS)</p></li></ul></li><li><p>20051018</p><ul><li><p>Added ToDos in special <todo> markup and now are visible as inline yellow tables, as well as a summary. An XSLT 'show.todos=0' variable will disable this output.(SS)</p></li></ul></li><li><p>20050810</p><ul><li><p>Changed CDR to CDF in <a href="#reqmt-richmultimedia"><b>3.1.1.15 CDF MUST provide the ability for content developers to describe
or author rich media content</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-baseset"><b>3.1.1.2 CDF MUST specify a base set of formats, corresponding
profiles and versions</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-genericintegrationtechniques"><b>3.1.1.8 CDF MUST specify generic integration techniques</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-temporalsync"><b>3.1.1.16
CDF MUST support temporal synchronization of dynamic content
coming from multiple references, possibly with multiple
references to the same source.</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-eventscrossnamespace"><b>3.1.1.9 CDF MUST support event mechanisms that cross namespace boundaries</b></a> (SS)</p></li><li><p>Changed CDR to CDF and added CDI content in <a href="#reqmt-scriptability"><b>3.1.1.10 CDF MUST support scriptability</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-nestinglevel"><b>3.1.1.11 CDF MUST specify the allowed nesting level of combinations</b></a> (SS)</p></li><li><p>Reworded to apply to CDI as well in <a href="#reqmt-crossnamespace-links"><b>3.1.1.17 CDF profiles MUST specify how focus traversal works with
compounding documents and languages.</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-crossnamespace-animations"><b>3.1.1.18 CDF profiles MUST specify triggering of animations across namespaces.</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-addingeventhandlers"><b>3.1.1.12 CDF profiles SHOULD provide a method for adding event
handlers using declarative markup for the formats it uses</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-accessibility"><b>3.1.1.19 CDF documents MUST cater for accessibility requirements</b></a> (SS)</p></li><li><p>Reworded to apply to CDI as well in <a href="#reqmt-dynamicupdating"><b>3.1.1.20 CDF documents MUST support dynamic updating</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-transport"><b>3.1.1.13 CDF must define its integration into the Web
Architecture. It must include delivery over HTTP and should also
strive to be transport independent</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-compression"><b>3.1.1.14 CDF MUST NOT prevent compression of the data</b></a> (SS)</p></li><li><p>Reworded to apply to CDI as well in <a href="#reqmt-unified-key-handling-across-CD"><b>3.1.1.21 CDF MUST define the way soft-keys and accesskeys are handled across document and language components</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-serversideadaptation"><b>3.1.1.23 CDF MUST NOT prevent server-side adaptation</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-limitedbandwidth"><b>3.1.1.24 CDF MUST support limited bandwidth networks and limited
capability devices</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-document-confirmance-criteria"><b>3.1.1.3 CDF Profiles MUST define clear document conformance criteria</b></a> (SS)</p></li><li><p>Changed CDR to CDF in <a href="#reqmt-useragent-conformance-criteria"><b>3.1.1.4 CDF Profiles MUST define clear user agent conformance criteria</b></a> (SS)</p></li><li><p>Added <a href="#reqmt-p2-profile1"><b>3.4.1.1 CDR & CDI Profile 2 - Mobile MUST also support CDI WICD Core and CDR WICD Profile 1 - Mobile Requirements</b></a> (SS)</p></li><li><p>Added <a href="#reqmt-p2-svg"><b>3.4.1.2 CDR & CDI Profile 2 MUST support SVG as a child language of XHTML</b></a> (SS)</p></li><li><p>Added <a href="#reqmt-p2-xforms"><b>3.4.1.3 CDR & CDI Profile 2 MUST support XForms as a child language of XHTML</b></a> (SS)</p></li></ul></li><li><p>20050809</p><ul><li><p>Renamed document from cdr->cdf (SS)</p></li><li><p>Removed 'by Reference' and added '2.0' in title (SS)</p></li><li><p>Changed the editors (moved previous Editors to <a href="#acknowledgements"><b>B Acknowledgements</b></a>) (SS)</p></li><li><p>Updated Status of this Document appropriately (SS)</p></li><li><p>Added placeholders for XML:id, XMLEvents, etc. in <a href="#relationships-with-other"><b>1.3 Relationships With Other Technologies</b></a> (SS)</p></li><li><p>Added definitions for CDI in <a href="#terms"><b>1.4 Definition of Terms</b></a> (SS)</p></li><li><p>Added XForms and form information to <a href="#use-cases"><b>2 Use Cases</b></a> (SS)</p></li><li><p>Updated introductory text for <a href="#requirements_cdr"><b>3.1 Framework</b></a> for CDI (SS)</p></li><li><p>Removed CDR from <a href="#reqmt-exploitexisting"><b>3.1.1.1 CDF MUST exploit existing specifications, favoring W3C
specifications wherever possible and limit the definition of new
markup unless absolutely required for integration purposes</b></a> (SS)</p></li><li><p>Added placeholder for section <a href="#rich_multimedia_content_requirements_prof2"><b>3.4 CDI & CDR WICD Profile 2</b></a> (SS)</p></li></ul></li></ul></div><div class="div1">
<h2><a name="todos" id="todos"></a>D Remaining items to complete this document (Non-Normative)</h2></div><table class="todo" bgcolor="yellow" border="1"><caption><em>Summary of ToDos in this Document</em></caption><tr><td><b>ToDo</b></td><td><b>Owners</b></td></tr><tr><td><a href="#todo.wicdintro">Give WICD an appropriate introduction</a></td><td>Steve Speicher</td></tr><tr><td><a href="#todo-defs-fwk-prof">Should we add 'framework' and 'profile' to definitions</a></td><td>Steve Speicher</td></tr><tr><td><a href="#content-type">Need to consolidate "identification of markup" requirements</a></td><td>Steve Speicher</td></tr><tr><td><a href="#todo-req-fmwk-cdi">Framework reqs for CDI</a></td><td>Steve Speicher</td></tr><tr><td><a href="#todo-core-incl">WICD Core CDI reqs</a></td><td>Steve Speicher</td></tr><tr><td><a href="#todo.req-prof2-content">Determine content for CDI Profile 2</a></td><td>Steve Speicher</td></tr><tr><td><a href="#todo.reqmt-p2-xforms-svg">Complete the list of Profile 2 requirements</a></td><td>Need Help</td></tr><tr><td><a href="#todo.refs">Update references</a></td><td>Steve Speicher</td></tr></table></div></body></html>