February 2013 - oXygen-sdk - www.oxygenxml.com

Re: [oXygen-sdk] CMS integration: Resolving images
by Pascal Beutels 08 Feb '13

08 Feb '13

Then we probably need a RelativeReferenceResolver for our protocol when inserting e.g. images? ------------------------------ Message: 2 Date: Mon, 4 Feb 2013 08:25:33 -0000 From: "Pascal Beutels" <pbeutels(a)sdl.com> Subject: [oXygen-sdk] CMS integration: Resolving images To: <oxygen-sdk(a)oxygenxml.com> Message-ID: <D7B7EA2108156F42BEC04DEF9C75D66301303CDC(a)emeamail0304.global.sdl.corp> Content-Type: text/plain; charset="us-ascii" Hi, We are creating a plugin for oXygen (14.1) for our DITA based repository. All the content is stored in our repository, also the images, .... When e.g. a topic contains an image element, it only contains the unique identifier: <image href="GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85" placement="break"> What would be the best way to resolve this. Are there hooks foreseen in oXygen we can use? Does oXygen require that this image is on the file system (in other words does it expect a file path)? The same for internal links and conrefs. Kind regards, Pascal Beutels

2 3

Re: [oXygen-sdk] Overwriting or Extending the DITA framework
by Pascal Beutels 07 Feb '13

07 Feb '13

Hi, Our final intent is to deliver an MSI that customers of our DITA repository can install so they can use oXygen xml editor to check ou/check in/View/... documents from our repository. The documents are always downloaded to a (configurable) location on the local hard disk, so no WebDAV support. -Pascal -----Original Message----- From: oxygen-sdk-bounces(a)oxygenxml.com [mailto:oxygen-sdk-bounces@oxygenxml.com] On Behalf Of oxygen-sdk-request(a)oxygenxml.com Sent: maandag 4 februari 2013 19:00 To: oxygen-sdk(a)oxygenxml.com Subject: oXygen-sdk Digest, Vol 4, Issue 2 Send oXygen-sdk mailing list submissions to oxygen-sdk(a)oxygenxml.com To subscribe or unsubscribe via the World Wide Web, visit http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk or, via email, send a message with subject or body 'help' to oxygen-sdk-request(a)oxygenxml.com You can reach the person managing the list at oxygen-sdk-owner(a)oxygenxml.com When replying, please edit your Subject line so it is more specific than "Re: Contents of oXygen-sdk digest..." Today's Topics: 1. Re: Overwriting or Extending the DITA framework (Oxygen XML Editor Support) 2. CMS integration: Resolving images (Pascal Beutels) 3. Re: CMS integration: Resolving images (Oxygen XML Editor Support) ---------------------------------------------------------------------- Message: 1 Date: Mon, 04 Feb 2013 09:29:05 +0200 From: Oxygen XML Editor Support <support(a)oxygenxml.com> Subject: Re: [oXygen-sdk] Overwriting or Extending the DITA framework To: oxygen-sdk(a)oxygenxml.com Message-ID: <510F6341.2040003(a)oxygenxml.com> Content-Type: text/plain; charset=windows-1252; format=flowed Hi Pascal, What is your final intent? Do you want to distribute a plugin which can be installed into any Oxygen installation to allow validation and editing support for your slightly modified DITA content? We have some API like: > ro.sync.exml.workspace.api.util.XMLUtilAccess.addPriorityEntityResolve > r(EntityResolver) which would allow you to return your own DTD content when certain DITA public IDs are resolved. This would work for validating and providing content completion for your type of documents. But the API does not allow you to see for which XML content the entity resolver was called because the catalog resolver is called from many parts of the editor. Usually this kind of customization is done by distributing a custom framework (which can be a copy of our DITA framework with some things changed). A custom framework can also be distributed like an addon together with the plugin. > These customizations also require special rendering in the Author view, so we also need to extend the standard DITA css files. We do not (yet) have Java API which would allow you to add an additional CSS content for rendering a certain opened XML document. In Oxygen 14.2 (in a couple of weeks) we will add a special type of plugin extension which will allow you to add a StylesFilter (ro.sync.ecss.extensions.api.StylesFilter) > We can make the distinction between standard DITA and DITA files > coming from our repository, so we would like to do this without > changing the default behavior of DITA files not coming from our > repository You could create your own framework (document type) starting by copying our DITA document type. In the Preferences->"Document Type Association" page your document type would be placed before the usual DITA one (a document type has a priority field which can be increased). And your document type would have an association rule which would match only your type of XML documents (you can implement an interface "ro.sync.ecss.extensions.api.DocumentTypeCustomRuleMatcher" to create a custom rule matcher). If you have a custom DITA document type, you can change the CSS and catalogs in it to suit your situation. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 2/1/2013 5:16 PM, Pascal Beutels wrote: > Hi, > > We are creating a plugin for oXygen (14.1) for our DITA based repository. > > We have some customizations (not specializations) on the DITA DTD?s, > but our DITA files contain the standard DITA public id?s. > > Is there a way to extend the oXygen DITA framework, so we can ?inject? > our catalog instead of the default DITA catalog? > > These customizations also require special rendering in the Author > view, so we also need to extend the standard DITA css files. > > We can make the distinction between standard DITA and DITA files > coming from our repository, so we would like to do this without > changing the default behavior of DITA files not coming from our > repository > > Kind regards, > > Pascal > > > > _______________________________________________ > oXygen-sdk mailing list > oXygen-sdk(a)oxygenxml.com > http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk > ------------------------------ Message: 2 Date: Mon, 4 Feb 2013 08:25:33 -0000 From: "Pascal Beutels" <pbeutels(a)sdl.com> Subject: [oXygen-sdk] CMS integration: Resolving images To: <oxygen-sdk(a)oxygenxml.com> Message-ID: <D7B7EA2108156F42BEC04DEF9C75D66301303CDC(a)emeamail0304.global.sdl.corp> Content-Type: text/plain; charset="us-ascii" Hi, We are creating a plugin for oXygen (14.1) for our DITA based repository. All the content is stored in our repository, also the images, .... When e.g. a topic contains an image element, it only contains the unique identifier: <image href="GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85" placement="break"> What would be the best way to resolve this. Are there hooks foreseen in oXygen we can use? Does oXygen require that this image is on the file system (in other words does it expect a file path)? The same for internal links and conrefs. Kind regards, Pascal Beutels

2 1

CMS integration: Resolving images
by Pascal Beutels 04 Feb '13

04 Feb '13

Hi, We are creating a plugin for oXygen (14.1) for our DITA based repository. All the content is stored in our repository, also the images, .... When e.g. a topic contains an image element, it only contains the unique identifier: <image href="GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85" placement="break"> What would be the best way to resolve this. Are there hooks foreseen in oXygen we can use? Does oXygen require that this image is on the file system (in other words does it expect a file path)? The same for internal links and conrefs. Kind regards, Pascal Beutels

2 1

Overwriting or Extending the DITA framework
by Pascal Beutels 04 Feb '13

04 Feb '13

Hi, We are creating a plugin for oXygen (14.1) for our DITA based repository. We have some customizations (not specializations) on the DITA DTD's, but our DITA files contain the standard DITA public id's. Is there a way to extend the oXygen DITA framework, so we can 'inject' our catalog instead of the default DITA catalog? These customizations also require special rendering in the Author view, so we also need to extend the standard DITA css files. We can make the distinction between standard DITA and DITA files coming from our repository, so we would like to do this without changing the default behavior of DITA files not coming from our repository Kind regards, Pascal

2 1