pure XML

[Chris Despopoulos]

I agree with Michael on this...  You can't use the FrameMaker conditional text feature with other editors because, well, you can't. So the Maker PIs make no sense and are correctly ignored by those editors.  OTOH, nothing prevented you from using special show/hide attributes in Maker.  As I recall, earlier versions even had a way to deal with them, didn't they?  Was it through the EDD, or was it through r/w rules???  I forget (or am I dreaming?).  Anyway, you could always have written a plugin that would do the right thing.  (And building plugins or other modifications for editors is not unusual, as I understand it.)

For Maker 9, they've just built attribute filtering directly into the product. No doubt via a plugin on the rendering side.  Who wants to bet some special variant of conditional text is involved?  You can use that, or you can use standard conditional text, or both.  There may be cases where you would want to use Maker conditional text.

This is an example of how the markup model evolved apart from the Maker model (a good thing, and pretty much by definition), and how the Maker model was modified to catch up.  Not every editor implements every possible markup construct out of the box.  No editor renders markup natively except for text editors.  As far as I know, since Maker 8 (UNICODE) the significant limitation to Maker is in tables (no tables within tables -- can you live with that limit, yes or no?).  Otherwise, you should be able to bend Maker to any markup's will.  Whether Adobe foots the bill is strictly a marketing decision.

I still wish the API explicitly supported injecting custom IDs in elements.

cud

>Am 17.02.2010 um 16:33 schrieb Sarah O'Keefe:
>
>> So, if you use the original FrameMaker model of conditional text, you  
>> will have interoperability problems. There are other features with  
>> similar issues.
>
>Isn't "interoperability" more a question of process design than of product features? 
>
>I
doubt whether two arbitrary XML editors are interoperable in all
editing aspects. It seems to me, 
>that every editor has its own 
>take on
tracking changes, for example. Also handling of tables and support for
graphics come to my mind.
>
>- Michael