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

 


Help: OASIS Mailing Lists Help | MarkMail Help

docstandards-interop-discuss message

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


Subject: RE: [docstandards-interop-discuss] Clarifications / Scope of the intended work?


David,

Respectfully, I believe the issue isn't at the presentation layer but more
at the content layer:  How do I leverage/reuse/repurpose content in one XML
Standard (say DITA) in my content (say DocBook)? Here the question is more
targeted at content interoperability. For example, Vendor A provides content
to an OEM partner who will rebrand it and integrate Vendor A's content into
their own doc set (could be PDF, HTML, HTML Help, JavaHelp, or any number of
formats).  Further down the pipeline, the content is reused in Training
material by a different group using TEI. 

In these cases, the structural and semantic characterists are equally
important:  a procedure may appear as a numbered list presentationally, but
semantically it is very different than a set of items in a sequenced list.

By abstracting each XML standard's specific content models to a common
denominator, you can preserve structure along with semantics in a way that
enables other XML standards to leverage the content using their grammar with
minimal loss to semantics from the original.

Certainly, there are cases as you mentioned that require the presentational
functionality to be preserved "as submitted" that do not apply here. And in
these cases, your approach to maintaining the presentational semantics is
very interesting. I've used iText for personal projects, and yes, it is very
mature. 

Cheers,

Jim

================
Jim Earley
XML Developer/Consultant
Flatirons Solutions
4747 Table Mesa Drive
Boulder, CO 80301

Voice: 303.542.2156
Fax:   303.544.0522
Cell:  303.898.7193

Yahoo.IM: jmearley
MSN.IM: jearley22@hotmail.com

jim.earley@flatironssolutions.com
-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info] 
Sent: Tuesday, April 10, 2007 9:02 AM
To: Earley, Jim
Cc: Dave Pawson; docstandards-interop-discuss@lists.oasis-open.org
Subject: RE: [docstandards-interop-discuss] Clarifications / Scope of the
intended work?

Jim,
 
Why not focus on the handling functions instead?  That way you are an
abstraction layer above the lowlevel representation syntax.  
 
The xhtml is problematic - especially when it comes to page counts and page
content.  Legally also - you need to leave things "as submitted" - because
you may reject a submission as say not having content in the right place on
a page, or total pages - and yet the original was OK when viewed in the
native format.
 
Also - by going with functions - you put the onus on the individual tool
vendors to support those functions consistently - without having to get into
the lower level syntax ourselves of how that occurs, either now or future
new formats.
 
At the end of the day it is the BUSINESS FUNCTIONALITY that you want
interoperability around - not the raw document.
 
So from the business stance - if I need to check for certain bookmarks,
sections, text strings, page counts, word counts, etc - I can do that.
 
DW

"The way to be is to do" - Confucius (551-472 B.C.)




	-------- Original Message --------
	Subject: RE: [docstandards-interop-discuss] Clarifications / Scope
of
	the intended work?
	From: "Earley, Jim" <Jim.Earley@flatironssolutions.com>
	Date: Tue, April 10, 2007 10:46 am
	To: "Dave Pawson" <dave.pawson@gmail.com>,
	<docstandards-interop-discuss@lists.oasis-open.org>
	
	
	Dave,
	
	The current thinking with regard to a solution uses XHTML
Microformats as
	the abstraction layer. All of the standards (DITA, DB, ODF) share
the
	same
	structural characteristics (Headings, paragraphs, lists, tables,
images,
	etc.) albeit in different ways. 
	
	The premise thus far is: 
	
	1. use standard XHTML markup for common semantic/structural
components
	(table, img, p, ol, acronym, strong, em, etc)
	2. For structural components that do not have an equivalent XHTML
	mapping,
	use <div>
	3. For inline semantics that do not have an equivalent XHTML
mapping, use
	<span>
	
	- use the title attribute (available on any XHTML element) to store
the
	original element name
	- use the class attribute to store the "semantic category": e.g.,
	"procedural" vs. "list" to delineate between a procedural set of
steps
	compared to a numbered list
	
	- there are a couple of ideas that we're playing with with regard to
	capturing the attribute values from the original source:
	
	a) Use the object tag (with child param tags to capture the
name/value
	pairs)
	b) Use a declared namespace to embed the attributes on the element
	
	These are, of course, open for discussion. 
	
	Jim
	
	
	================
	Jim Earley
	XML Developer/Consultant
	Flatirons Solutions
	4747 Table Mesa Drive
	Boulder, CO 80301
	
	Voice: 303.542.2156
	Fax:   303.544.0522
	Cell:  303.898.7193
	
	Yahoo.IM: jmearley
	MSN.IM: jearley22@hotmail.com
	
	jim.earley@flatironssolutions.com
	-----Original Message-----
	From: Dave Pawson [mailto:dave.pawson@gmail.com] 
	Sent: Tuesday, April 10, 2007 8:12 AM
	To: docstandards-interop-discuss@lists.oasis-open.org
	Subject: Re: [docstandards-interop-discuss] Clarifications / Scope
of the
	intended work?
	
	On 10/04/07, Michael Priestley <mpriestl@ca.ibm.com> wrote:
	
	> - govt worker begins drafting a policy note in ODF with the
subject
	"the
	use of personal data received via email"
	> - govt worker pulls in the text of the relevant statute, which is
in a
	DITA specialization
	> - govt worker pulls in the legal disclaimer which must now be
	included in
	every government email reply, from a different DITA specialization
	> - govt worker pulls in the instructions on how to include the text
	of the
	disclaimer in emails, from documentation of the email software
written in
	DocBook
	
	> - technical author 2, using DocBook, creates a customized version
of
	the
	email software documentation
	> - and pulls in portions of the procedures web site, in the form of
DITA
	topics and ODF policy notes
	
	OK, you've described the problem Michael. I hope we can all
sympathise
	with that!
	
	Ignoring how, what do you see as a solution?
	
	A means of 'integrating' n streams?
	A way of reading n streams?
	A means of generating .... something readable by all.... (lcd
solution)
	
	What class of solution is the goal please?
	
	
	regards
	
	
	-- 
	Dave Pawson
	XSLT XSL-FO FAQ.
	http://www.dpawson.co.uk <http://www.dpawson.co.uk/> 
	
	
---------------------------------------------------------------------
	To unsubscribe, e-mail:
	docstandards-interop-discuss-unsubscribe@lists.oasis-open.org
	For additional commands, e-mail:
	docstandards-interop-discuss-help@lists.oasis-open.org
	

BEGIN:VCARD
VERSION:2.1
N:Earley;Jim
FN:Jim Earley
ORG:Flatirons Solutions
TITLE:XML Developer/Consultant
TEL;WORK;VOICE:303.542.2156
TEL;CELL;VOICE:303.898.7193
ADR;WORK:;;4747 Table Mesa Rd, Suite 200;Boulder;CO;80305;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:4747 Table Mesa Rd, Suite 200=0D=0ABoulder, CO 80305=0D=0AUnited States of A=
merica
URL;WORK:http://www.flatironssolutions.com
EMAIL;PREF;INTERNET:Jim.Earley@flatironssolutions.com
REV:20060614T132755Z
END:VCARD

smime.p7s



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