[kilechki]

Hello everyone

I did not hear anything about this on these board, although it seems most important for the future of the Mac. Nisus, the Omnigroup and Blacksmith seem to intend to create a new OpenDoc type technology. The goals and scenarios presented on the website are very cool and usefull.
Does that mean, however, that Apple will leave unused Nexstep's technology in this area? This would be sad, for all applications would benefit from such a move.... Maybe Gregomni can give us some feedback on this?

PS : sorry for the bad english...

[zizban]

This was on the MacNN front page. Its interesting but I'd like to see details.

[Millennium]

Way back in The Day, a complete implementation of OpenDoc for NeXTStep (OSX's predecessor) existed, though I'm not sure it was ever used for very much. This didn't make it into OSX, and I've never been quite sure why. Amelio killed it on OS9, not Steve, and Steve apparently approved of the idea enough to allow it in NeXTStep.

This new idea is not OpenDoc, nor does it seem to bear very many similarities to it in a technical sense. The point of OpenDoc was that it would work through a collection of "components" which weren't applications on their own, but provided bits of functionality as though they were. These components could integrate with each other to do things that they could not have done on their own, and actual applications could also work with these components if they were written to do so. This kind of design has many advantages and disadvantages, but back in its day the main advantage was supposed to be that it would reduce software bloat, because each vendor could concentrate on what it did best and wrap that functionality up in a component. You could then, for example, roll your own word processor out of a text editor, a spell checker, and possibly some graphics or spreadsheet tools. These components need not all be from the same company; the interoperability frameworks would ensure that it all Just Worked.

Linkback, by contrast, seems to be about making complete applications talk to one another, so that one app could display its data in another app. This was possible in OpenDoc too, though it probably wouldn't have been implemented this way. More likely each app would provide a simple viewer component for its data, possibly even offering it for download separately from the app so that anyone could view but not edit data made by it. As currently implemented, though, someone who wanted to view a document from a LinkBack-enabled app would need all of the applications used to create that document.

I use OmniOutliner and NWE, so I just might check this out. However, this is not OpenDoc by any stretch of the imagination. It solves some of the same problems OpenDoc does, but not in a way that it can solve them all. This said, a LinkBack browser plugin would just plain rock.

[larkost]

Millennium: you nearly have it... the one statement that I am going to disagree with is that I don't see any way to have a browser plugin for this. LinkBack simply adds another bit of data onto the pasteboard with the data that the originating application would need to reconstruct an editable copy of the data it is sending. The program receiving the paste command still has to be able to do something with one of the other representations on the pasteboard (pdf, text, etc...) and that is what it actually displays.

The LinkBack information can also include a hook to tell the receiving application to periodically check for an updated set of data. To take the stock ticker example: the user selects a range of stock quotes in MyStockTicker and copies them. Then the user opens MyTextEdit and pastes that into a new document. A dialog box pops up (from MyTextEdit) and asks whether this data should refreshes itself periodically, and the user chooses ever 15 minutes. MyTextEdit then adds an image box (a custom class for LinkBack images) into the text area and displays the PDF data that it found on the pasteboard with a nice layout of the selected stock's actions for the day. It also stuffs the data from the LinkBack format that was also on the pasteboard into a special slot in the image box and sets a timer to refresh that data in 15 minutes. 15 minutes later the timer fires and MyTextEdit gives the data that it suffed into the image box back to the LinkBack framework, and it in turn asks MyStockTicker to give it a new version of the original copy based on the data that it got from MyTextEdit. The repose from this goes back through the LinkBack framework to MyTextEdit and the image gets updated, presumably with the latest stock information (once again as a PDF with a side order of LinkBack information.. in the form of a plist).

No-where in this process is there really room for a browser plugin. The refreshing of the data you could simply do with a update tag in a html page containing an image tag.

[theolein]

As they say on the web page, this is not OpenDoc in any form. Rather, it is similar to Microsoft's OLE (Object Linking and Embedding), which is referrred to as ActiveX these days. It's also similar to Classic MacOS' Publish and Subscribe. Whatever the case, I think it's a wonderful idea but ideally it needs to be implemented as a core framework so that all applications can use it. As it now stands applications will have to be rewritten to take advantage of this.

[Millennium]

Originally posted by theolein:
As they say on the web page, this is not OpenDoc in any form. Rather, it is similar to Microsoft's OLE (Object Linking and Embedding), which is referrred to as ActiveX these days.

OLE and OpenDoc share more similarities than OLE and LinkBack do. OLE, just as with OpenDoc, works with the concept of components at its core; that's what ActiveX controls are. Linkback, once again, is set to work mostly with applications.

Furthermore, it appears that Linkback is designed for read-only access to data. OpenDoc and OLE both allow for reading and editing.

Whatever the case, I think it's a wonderful idea but ideally it needs to be implemented as a core framework so that all applications can use it.

They already can; the framework was open-sourced.

As it now stands applications will have to be rewritten to take advantage of this.

They'll have to be rewritten anyway, whether or not it's a core framework. Just because it's Cocoa doesn't mean it comes "for free".

[barney ntd]

Originally posted by Millennium:
They'll have to be rewritten anyway, whether or not it's a core framework. Just because it's Cocoa doesn't mean it comes "for free".

If Apple added support for this to the cocoa text engine, a lot of apps (including TextEdit) would get it for free. It seems to me that this is probably necessary for it to really catch on. Still, it's a good enough idea that I'm thinking of adding support to Border (shameless plug!). It looks easy enough to add to any app which already supports drag&drop or copy&paste.

Barney.

[aabernathy]

Originally posted by Millennium:
Way back in The Day, a complete implementation of OpenDoc for NeXTStep (OSX's predecessor) existed, though I'm not sure it was ever used for very much. This didn't make it into OSX, and I've never been quite sure why. Amelio killed it on OS9, not Steve, and Steve apparently approved of the idea enough to allow it in NeXTStep.

I think you're misremembering. I'm not aware of any OpenDoc implementation ever existing for NeXTstep - it certainly never came bundled with such.

What NeXTstep did have (eventually - this was introduced well into the NeXTstep timeline) was a mechanism for linking data from one document into a second document, and the documents could be from separate applications. It's been a long time and I can't recall the name of the technology, but I remember it getting a prominent demo in one of the NeXTworld keynotes. This mechanism allowed the user to specify the granularity of the updates - you might only have the second document update when the first document was saved, or you could have the changes distributed immediately. (In the latter case, due to the architecture, I remember that you usually would see the change reflected in the subscribing document before it was shown in the publishing document.)

For example, you could draw something in the simple drawing app that came with NeXTstep, paste as link into a TextEdit document, and then as you made changes to the drawing, the pasted graphic in TextEdit would update to reflect those changes. There was a mechanism for "breaking" the link, effectively turning the linked paste into a normal paste after the fact; and a mechanism for relocating the original document if it moved and the subscribing document was unable to find it.


You most likely find a lot of that familiar. :-) But I think it's what you're remembering, and it definitely wasn't OpenDoc - there was no editing within the context of the subscribing document.

-andrew (who started working on NeXTstep just before NeXTstep 2.0 was released)

[goMac]

Yeah, I don't think OpenDoc was never on NeXTStep. It was very much Apple only, and was killed by Mac OS 8.5.

[TETENAL]

Originally posted by goMac:
Yeah, I don't think OpenDoc was never on NeXTStep. It was very much Apple only, and was killed by Mac OS 8.5.

I don't know whether it was ever on Next, but it was not very much Apple only since it was developed together with IBM and Novell.

[Diggory Laycock]

Yay! Publish & Subscribe rises from the grave!

[Millennium]

Originally posted by aabernathy:
I think you're misremembering. I'm not aware of any OpenDoc implementation ever existing for NeXTstep - it certainly never came bundled with such.

It may have been slated for 4.0, then (which, IIRC, was never released). I clearly remember reading marketing information about this, and several NeXTStep developers have also commented on it; I'll see if I can find the articles again. I'm not sure it ever went GM, though.

[aabernathy]

Originally posted by Millennium:
It may have been slated for 4.0, then (which, IIRC, was never released). I clearly remember reading marketing information about this, and several NeXTStep developers have also commented on it; I'll see if I can find the articles again. I'm not sure it ever went GM, though.

NeXTstep was renamed to OPENSTEP at the 4.0 mark. There was indeed initially a more-broadly-scoped release planned for 4.0 (with a significantly changed UI), and a hard-to-get prerelease did make the rounds at the time, but as NeXT's plans changed, so did the scope for 4.0, which ended up being a much less dramatic change from 3.x.

I'm very interested in any articles you can find about OpenDoc for NeXTstep or OPENSTEP; I would be really surprised to find such a thing was planned and I'm only now hearing about it. :-)

-andrew

[BHD]

One thing that seems to be missing from LinkBack is a way to address the problem that as a user I am more concerned about than application interoperability: data portability and openness.

RTF is not sufficient to passing around the sort of semantic content that real users deal with. OmniOutliner 3 has some really impressive new XML capabilities. One can, for example, tag a phrase of text with a named character style. Because it has an XSLT-based plug-in system, one can easily map those characer styles to different output.

What I want is to be able to open my OO file in an app like Nisus Express and have all of that logic intact. I want to be able to export that content wherever I am to XHTML or DocBook or whatever; again with the semantic logic intact.

So, if Apple won't do it, how about a standardized XML text representation for the pasteboard, complete with named character styles (and a list of default styles)? All LinkBack projects would then be able to read/write this format.

I think the file format on which OpenOffice is based -- now called OpenDocument, and headed for ISO approval -- would probably be ideal. It's well-designed, and it's modularized into a variety of different namespaces (text, graphics, tables, etc.). The project could just support the "text" namespace, and gradually add in other namespaces as needed.

[HOMBRESINIESTRO]

Originally posted by BHD:
I think the file format on which OpenOffice is based -- now called OpenDocument, and headed for ISO approval -- would probably be ideal. It's well-designed, and it's modularized into a variety of different namespaces (text, graphics, tables, etc.). The project could just support the "text" namespace, and gradually add in other namespaces as needed.

Do you mean OASIS? I've talked to Ori Redler (maker of Mellel) and asked him about implementing it in Mellel. I went even a step furhter and asked for it as the default file format. He had some interesting info on how OASIS was merely the file format especially for OpenOffice/StarOffice. It has many things that are necessary for OpenOffice and unnecessary for e.g. Mellel and therefore this one is not streamlined at all. Moreover he said OASIS wouldn't support some of the "features" that Mellel would need without making additions to it (and with them being not compatible with the standart anymore).

After hearing this, and I have to say that I do believe Ori without being able to do research on this on myself, I would object OASIS being the default file format for the pasteboard in OS X. I think we would need something more flexible.

[BHD]

Originally posted by HOMBRESINIESTRO:
Do you mean OASIS? I've talked to Ori Redler (maker of Mellel) and asked him about implementing it in Mellel. I went even a step furhter and asked for it as the default file format. He had some interesting info on how OASIS was merely the file format especially for OpenOffice/StarOffice. It has many things that are necessary for OpenOffice and unnecessary for e.g. Mellel and therefore this one is not streamlined at all. Moreover he said OASIS wouldn't support some of the "features" that Mellel would need without making additions to it (and with them being not compatible with the standart anymore).

After hearing this, and I have to say that I do believe Ori without being able to do research on this on myself, I would object OASIS being the default file format for the pasteboard in OS X. I think we would need something more flexible.

It is currently managed by an OASIS TC, but is going through the process of ISO approval as well.

As for Ori's point, KOffice -- written on an entirely different codebase -- will also be implementing the format, so I'm a little suspicious of his claim. It sounds to me like a typical NIH response so common in the Mac world (and Apple's guilty of this too, mind you).

And as I said, it ought to be possible to take pieces of it to implement.

As for me, I'm not interested in an application that isn't focused on standards. Hell, I'm starting to become disillusioned with the entire Mac platform for exactly this reason. Simply saying you're doing to move to an XML file format means nothing; the devil is in the details.

[Millennium]

Just moving to XML doesn't do any good. Raw XML with no DTD or specification is the ultimate in flexibility, but it doesn't mean anything and so it can't ever be ported with any hope of interoperability. Specifications give a format this kind of definition, but they also constrain it in terms of how flexible it is. It's entirely possible that Mellel might require some features not present in OASIS, though for the life of me I've no clue as to what they might be.

Apple tried the standard-formats thing, back during the earliest days of the Mac OS. At the time, of course, Apple defined almost all the formats; RTF was only in its infancy when styl resources were invented, and PICT predated GIF, PNG, PDF, and possibly even JPEG by years. All Mac apps knew about these formats, and relied on them for cut/paste functionality. It worked -hell; it worked much better than Microsoft's OLE-based system does even today- but it wasn't without its limitations.

OmniOutliner 3 has some really impressive new XML capabilities. One can, for example, tag a phrase of text with a named character style. Because it has an XSLT-based plug-in system, one can easily map those characer styles to different output.

What I want is to be able to open my OO file in an app like Nisus Express and have all of that logic intact. I want to be able to export that content wherever I am to XHTML or DocBook or whatever; again with the semantic logic intact.

This is impossible, particularly as regards XHTML; its specification simply doesn't allow for that kind of semantics. However, it goes further than that; every app which used this logic would basically have to reimplement OmniOutliner in order to understand the way the logic is encoded and to actually do anything with that encoded logic.

Actually, I take that back. It's not completely impossible, though it's impossible with LinkBack. What you need is OpenDoc, and you need an OmniOutliner component to go with it. This is why I'm so bitter about Amelio killing it; had Apple only persisted, written proper documentation and delivered the Finder-with-OpenDoc and ClarisWorks-as-OpenDoc that it promised, it could have been The Next Big Thing.

[BHD]

Originally posted by Millennium:
Just moving to XML doesn't do any good. Raw XML with no DTD or specification is the ultimate in flexibility, but it doesn't mean anything and so it can't ever be ported with any hope of interoperability. Specifications give a format this kind of definition, but they also constrain it in terms of how flexible it is.

Exactly, and that constraint is precisely what makes interoperablity possible. Without constraints, you don't have the web.

Apple tried the standard-formats thing, back during the earliest days of the Mac OS. At the time, of course, Apple defined almost all the formats; RTF was only in its infancy when styl resources were invented, and PICT predated GIF, PNG, PDF, and possibly even JPEG by years. All Mac apps knew about these formats, and relied on them for cut/paste functionality. It worked -hell; it worked much better than Microsoft's OLE-based system does even today- but it wasn't without its limitations.

I'm not really following the logic here. RTF is the default text representation in Cocoa, and has been since it's original inception more than 15 years ago. I'm just saying, let's bring it into the 21st century and use XML instead. There are all kinds of practical reasons why this would be valuable.

This is impossible, particularly as regards XHTML; its specification simply doesn't allow for that kind of semantics. However, it goes further than that; every app which used this logic would basically have to reimplement OmniOutliner in order to understand the way the logic is encoded and to actually do anything with that encoded logic.

I'm not saying all the OO logic ought to travel. I'm talking about basic ways by which text and styles and such are represented; the stuff (poorly) covered by RTF now.

[Millennium]

Originally posted by BHD:
Exactly, and that constraint is precisely what makes interoperablity possible. Without constraints, you don't have the web.

Exactly. This is why XML for XML's sake is bad, just as Cocoa for Cocoa's sake is bad. There are legitimate reasons -in fact, plenty of legitimate reason- to use either of these technologies, but if you haven't thought it through and considered why you're using it, then there is no reason to do so.

I'm not really following the logic here. RTF is the default text representation in Cocoa, and has been since it's original inception more than 15 years ago. I'm just saying, let's bring it into the 21st century and use XML instead. There are all kinds of practical reasons why this would be valuable.

Name some. RTF is actually quite capable, and at this point changing it stands to break a lot of code which depends on that format. There needs to be a compelling reason to switch.

I'm not saying all the OO logic ought to travel. I'm talking about basic ways by which text and styles and such are represented; the stuff (poorly) covered by RTF now.

I don't understand. RTF is quite capable of handling lists, styles (including stylesheets), and such. Its most recent incarnations can even handle tables and footnotes.

[BHD]

Originally posted by Millennium:
Exactly. This is why XML for XML's sake is bad, just as Cocoa for Cocoa's sake is bad.

Nowhere did I suggest "XML for XML's sake." I was totally explicit that I had a specific—quite functional—schema in mind. I even gave some specific reasons why it would be valuable.

I don't understand. RTF is quite capable of handling lists, styles (including stylesheets), and such. Its most recent incarnations can even handle tables and footnotes.

How about: nested styles, better international support, citations, etc.?

[Millennium]

Originally posted by BHD:
Nowhere did I suggest "XML for XML's sake." I was totally explicit that I had a specific—quite functional—schema in mind. I even gave some specific reasons why it would be valuable.



How about: nested styles, better international support, citations, etc.?

Nested styles are a go. I'm not sure what you mean by 'better international support', given that the version of RTF which Apple uses supports many different encodings.

When it comes to citations you've got me; RTF supports footnotes but not semantic citations in the manner of BibTeX or even Word. That said, does a common cut/paste format really need to go into that much detail? Apple does not need to build a word processor into OSX.

[BHD]

Originally posted by Millennium:
Nested styles are a go. I'm not sure what you mean by 'better international support', given that the version of RTF which Apple uses supports many different encodings.

When it comes to citations you've got me; RTF supports footnotes but not semantic citations in the manner of BibTeX or even Word. That said, does a common cut/paste format really need to go into that much detail? Apple does not need to build a word processor into OSX.

Clearly you're not an academic. Citations are perhaps the most critical content than scholars deal with, and without the ablity to pass around the semantic content, why bother at all; just use Word and Endnote (neither very good apps, and better on Windows).

My understanding was RTF does not support nested named character styles.

International support: in XML it's easy to tag a phrase with a language attribute. You can't do that with RTF AFAIK.

[Millennium]

Originally posted by BHD:
Clearly you're not an academic.

Guess again.

Citations are perhaps the most critical content than scholars deal with, and without the ablity to pass around the semantic content, why bother at all; just use Word and Endnote (neither very good apps, and better on Windows).

Why would you be pasting text between apps while trying to keep citations intact? This would require (among other things) copy/pasting all of the bibliographical data along with the actual text being posted, which in turn means copy/pasting data which the user didn't necessarily want to copy.

That's a usability issue. Not only that, but there is virtually no publicly-available content which contains information like this except for that which is passed between individuals, and in almost none of these cases is a user going to be copy/pasting content between documents. What you're asking for is a solution in search of a problem.

International support: in XML it's easy to tag a phrase with a language attribute. You can't do that with RTF AFAIK.

Ah, so you're talking about using multiple languages within a single document, and then pasting multiple-language text at once. This is a very rare operation, and even when done it's even rarer that the language information is needed or even desired when the user copy/pastes.

What you want is a word processor embedded in the OS. I will switch away from any OS which bloats itself that badly.

[TETENAL]

RTF supports Unicode, so you can have all the languages of the world in a single document.

[Millennium]

Originally posted by TETENAL:
RTF supports Unicode, so you can have all the languages of the world in a single document.

Text encoding isn't the problem here; what he wants is to semantically mark up arbitrary strings as other languages. For example, he wants to specify "This sentence is in French" in a document which is otherwise in English.

In HTML, this would work something like this:

Code:
<p lang="en-us">Semantic markup possesses style, grace, and a certain <span lang="fr">je ne sais quois</span>
that makes it infinitely preferable to presentational markup in most cases.</p>

The biggest use case I could see for something like this would have to do with text-to-speech software. If you've never heard English-speaking text-to-speech software try to process French -or the reverse, for that matter- I recommend it for hours of entertainment. If you semantically mark up what languages are used for certain parts of the text, then text-to-speech software could switch algorithms to pronounce each word in a manner appropriate to its language. I don't know of any software actually capable of doing this, but it would be useful to have around.

[TETENAL]

Originally posted by Millennium:
Text encoding isn't the problem here; what he wants is to semantically mark up arbitrary strings as other languages. For example, he wants to specify "This sentence is in French" in a document which is otherwise in English.

And why does he want to do that?

[BHD]

Originally posted by Millennium:
Why would you be pasting text between apps while trying to keep citations intact? This would require (among other things) copy/pasting all of the bibliographical data along with the actual text being posted, which in turn means copy/pasting data which the user didn't necessarily want to copy.

Why do you assume this? Just do like OpenOffice will be doing: have a citation element that includes both semantic coding and rendered text. Then have a system-level service for regenerating the output.

Be creative.

That's a usability issue. Not only that, but there is virtually no publicly-available content which contains information like this except for that which is passed between individuals, and in almost none of these cases is a user going to be copy/pasting content between documents. What you're asking for is a solution in search of a problem.

Sigh ... so let me get this straight. If I happen to work in LaTeX/BibTeX, it's perfectly feasible for me to pass around semantic citations; just copy-and-paste \cite{whatever} from an email window, to emacs, to TeXShop. The logic stays with the content, and this flexibility is eminently practical.

I then ask to be able to do the same thing with Cocoa apps—functionality that XML would enable—and you tell me this is a "solution in search of a problem"?

What you want is a word processor embedded in the OS. I will switch away from any OS which bloats itself that badly.

This conclusion doesn't at all follow from my argument. You're spreading FUD.

[BHD]

Originally posted by TETENAL:
And why does he want to do that?

It was just an illustration. I wouldn't want it, but I could imagine other people would.

[TETENAL]

Originally posted by BHD:
Why do you assume this? Just do like OpenOffice will be doing: have a citation element that includes both semantic coding and rendered text. Then have a system-level service for regenerating the output.

Any application can copy (or promise to copy) multiple and any flavour of data. If it makes sense for an application to copy citation information or any other additional information, they can do so in addition to TEXT, and RTF flavours. This is possible today without any fancy XML or OpenDoc or whatever.

So what are you talking about?

[BHD]

Originally posted by TETENAL:
Any application can copy (or promise to copy) multiple and any flavour of data. If it makes sense for an application to copy citation information or any other additional information, they can do so in addition to TEXT, and RTF flavours. This is possible today without any fancy XML or OpenDoc or whatever.

So what are you talking about?

Go back to the beginning: I am talking about standardizing semantic coding in Cocoa in ways that would enable richer interoperability than we currently see on the Mac. Simply saying one can use any-old content you want hardly addresses the issue.

You guys can stick your fingers in your ears as long as you like, but MS understands how to exploit this sort of technology, and is doing just that. Instead, Apple rolls it own poorly-designed XML formats for Pages and Keynote, and does nothing to open them up to extension/interoperability.

[staph]

Originally posted by Millennium:
Just moving to XML doesn't do any good. Raw XML with no DTD or specification is the ultimate in flexibility, but it doesn't mean anything and so it can't ever be ported with any hope of interoperability. Specifications give a format this kind of definition, but they also constrain it in terms of how flexible it is. It's entirely possible that Mellel might require some features not present in OASIS, though for the life of me I've no clue as to what they might be.

At a guess, OASIS might be lacking the following for Mellel:
• Secondary font — Mellel allows a defined secondary font to handle sections of the Unicode table not handled by your primary font (so you can type continuously from English to Polytonic Greek and back again without switching style);
• Multiple user-defined note streams.

I'm not an expert, but last time I looked at OASIS markup it was also not as strictly semantic as it could be (lots of inline styles, that kind of thing), which is anathema to the Redlers, who could be aptly described as style authoritarians. I'm prepared to be corrected on this point, btw.

The Redlers have explicitly stated on several occasions that they will be publishing a DTD, and will be inviting comment on it before they settle on it.

At any rate, it seems that what the Redlers, and their users (based on the discussion list) were interested in was XSLT-style transform, and ease of extracting semantic content from the file format. XML isn't primarily about interoperability for them, so much as giving their users greater control and flexibility over the information in the file, and adopting a human-readable format.

[BHD]

Originally posted by staph:
The Redlers have explicitly stated on several occasions that they will be publishing a DTD, and will be inviting comment on it before they settle on it.

I would hope they don't do a DTD if they're going to roll their own. RELAX NG is an order-of-magnitude better way to write an XML language.

At any rate, it seems that what the Redlers, and their users (based on the discussion list) were interested in was XSLT-style transform, and ease of extracting semantic content from the file format. XML isn't primarily about interoperability for them, so much as giving their users greater control and flexibility over the information in the file, and adopting a human-readable format.

The above would be a great start, though. Those priorities were clearly not a part of the design of the Apges and Keynote file formats.

[Millennium]

Originally posted by BHD:
Why do you assume this?

Because that is exactly what you are describing. I suspect I'm thinking at a lower level than what you are, but what you want requires what I describe by definition.

Sigh ... so let me get this straight. If I happen to work in LaTeX/BibTeX, it's perfectly feasible for me to pass around semantic citations; just copy-and-paste \cite{whatever} from an email window, to emacs, to TeXShop. The logic stays with the content, and this flexibility is eminently practical.

All the Clipboard passes around is raw data. Emacs and TeXShop are themselves nothing but text editors. The program which actually processes the data is LaTeX, no matter what text editor you are using. If you cut/paste your citation from one document into another document which doesn't already have the bibliographic information you're citing, you're going to run into trouble when you try to run LaTeX on your text.

What you're asking for is infinitely more complex than passing raw data: you want cross-application semantics. That is not going to work without severe OS bloat.

I then ask to be able to do the same thing with Cocoa apps—functionality that XML would enable—and you tell me this is a "solution in search of a problem"?

XML enables nothing (and incidentally, it wouldn't work with your LaTeX example). What you would need to do is specify some method for bibliographical semantics, and then require all apps to follow that standard. That is so far beyond the province of an operating system that it isn't even funny.

This conclusion doesn't at all follow from my argument.

No, it just takes it out to its logical conclusion. It is not my intent to spread FUD, only to point out the implications of your proposal.

[Millennium]

Originally posted by BHD:
I would hope they don't do a DTD if they're going to roll their own. RELAX NG is an order-of-magnitude better way to write an XML language.

Neither of these is a good way to write an XML language, or any language for that matter. A good way to write an XML language is to start by creating a real specification in English or some other human language, and then writing DTDs and schemas (XSD, RELAX-NG, or whatever you care to use) to fit it.

XML is a good tool, when it is used properly. However, when used for its own sake without a proper understanding of what's involved, it not only ceases to be beneficial but becomes outright harmful.

[BHD]

Originally posted by Millennium:
The clipboard passes around is raw data. Emacs and TeXShop are themselves nothing but text editors. The program which actually processes the data is LaTeX, no matter what text editor you are using. If you cut/paste your citation from one document into another document which doesn't already have the bibliographic information you're citing, you're going to run into trouble when you try to run LaTeX on your text.

And this is exactly the model I'm proposing, only encoded in XML instead of LaTeX. In OpenDocument, the recently approved new citation coding (which I wrote) contains two elements: citation-source and citation-body. The first contains content similar to a LaTeX \cite{whatever} tag, while the second contains the rendered text.

[BHD]

Originally posted by Millennium:
Neither of these is a good way to write an XML language, or any language for that matter. A good way to write an XML language is to start by creating a real specification in English or some other human language, and then writing DTDs and schemas (XSD, RELAX-NG, or whatever you care to use) to fit it.

XML is a good tool, when it is used properly. However, when used for its own sake without a proper understanding of what's involved, it not only ceases to be beneficial but becomes outright harmful.

You're just sounding pedantic here. I have not once here advocated XML-for-XML's-sake.

Of *course* you start with a spec, but in the real world implementations are always constrained by what's made possible (or not) by the technology. I constantly see people make design decisions that are shaped (often unconsciously) by such constraints.

Both DTDs and XSDs impose significant limitations on one's ability to translate a human language spec into something software will understand. Those limitations don't exist with RELAX NG.

An example is the Atom spec. It's defined in a natural language spec, with some sensible design choices. It can only be completely faithfully represented in RELAX NG.