OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Report on W3C Web Application and Compound Document workshop


Hi, Don:

I've appended my report for the DITA OASIS Technical Committee.


Thanks,


Erik Hennum
DITA Domains Architect
ehennum@us.ibm.com


------------------------------------------------------------
Report on W3C Web Application and Compound Document workshop


I attended the second day (Compound Documents) of the W3C Web Application and Compound Document workshop and presented the DITA perspective on compound document design (DITA specialization and modularity) and on document aggregation including fragments (DITA conref), nesting (DITA topic nesting), and collections (DITA map).

Attendees hadn't heard of DITA before and were interested, but the workshop was focussed on issues of interaction and rendering.  By compound documents, the workshop meant getting distinct components to work together at runtime.

The questions were:

*  What's the relationship of conref and conkeyref to XML Fragment Interchange?

http://www.w3.org/TR/xml-fragment

Paul can no doubt give us a lot of insight.  My perspective is that, like XML Fragment, DITA conref recognizes that the context is important for a referenced fragment.  Where XML Fragment identifies the actual context in the document instance, DITA conref uses the container element for the fragment in the context so the reference can appear in any valid context for the remote fragment.


*  How does DITA manage the timing of refreshing conrefs? Does DITA keep a snapshot of the last refresh so the content can be displayed if the remote resource isn't available?  

The DITA Technical Committee might want to consider such loosely coupled scenarios for conref and other referential processing.


*  How does DITA resolve discrepancies when the maintainer of the collected topic and the maintainer of the collecting map specify different styles or processing?

Again, the scenario is distributed.  The maintainer of the topics may be published them on the web and completely unaware that the maintainer of the map is consuming the topics.  (In the same way that a maintainer of a web page is unaware of who is linking to the web page.)  How would the topic publisher provide processing and styling so the map publisher could use or override it?  The DITA Technical Committee might be interested in thinking through the requirements for this scenario.


*  What's the relationships of DITA semantics to OWL / RDF semantics?

The DITA map and topic related links assert relationships between topics.  Where these relationships have formal semantics, the relationships can be expressed as RDF.  Similarly, the properties of topics in the DITA prolog could be expressed as RDF.


Regarding the workshop itself, members of the DITA Technical Committee may take an interest in monitoring the follow-on activity.  One idea proposed was a web client to replace the monolithic browser and its segregated plugins with a framework that integrates new functionality in a coherent web application user interface.  That change could have some significant impacts.

While the workshop did not uncover a significant fit for DITA, I'd like to thank the Technical Committee for the opportunity to represent the DITA perspective.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]