In beginning to read one item in that list, I've queued up what is my first book to read about the Darwin Information Typing Architecture (DITA), in my own Safari books queue, namely the text: DITA Best Practices: A Roadmap for Writing, Editing, and Architecting in DITA.
Corresponding to that new books subscription, yesterday I'd begun developing a draft edition for another 'blog article -- that article, focusing about DITA, as in developing a concept of DITA architecture and DITA in applications. That was in using the Blogaway app (Pro edition), on my tablet. I'm afraid it may as well remain in an unpublished draft edition, that article. Candidly -- in no short time after I've signed up with the Safari Books subscription service and begun reading about DITA -- presently, it's developed from an academic pursuit into a project idea. Likewise, it's such that I'd like to share about, as a project idea.
Of course, a project would not be able to take up a life of its own, in such short time. Beside the introduction that I'd tried to develop, in that unpbulished 'blog article, yesterday, but in a shorter sense of overview: Personally, I have some albeit limited knowledge about technical writing -- as namely with regards to a small number of document formats, such as the DocBook SGML DTD and DocBook 5 RELAX NG XML schema. I'm fairly well familiar with XML, more broadly, as a markup format.
Previous to yesterday, I'd read a little bit about DITA. In a sense, I'd thought it seemed like a kind of a cheerful little ray of sunshine about narrative XML documentation formats, in broad -- a topic that there might not seem to be too many rays of sunshine about, typically. Candidly, on reading only some little about applications of the DITA schemas -- furthermore, in my being familiar with a style of hypermedia markup conventions as developed in DocBook -- I was a little put-off about some of the conventions of XML syntax developed in DITA. Mainly, there are the syntax and semantics of linking, in DITA information sets -- more specifically, a small number of elements and attributes in DITA, such that those elements and attributes may serve to provide "hooks" for content replacement in DITA processing models, as I've now begun to understand-- in a sense, those confuse me otherwise. I think there's a substantial difference in how DITA develops a concept of hypermedia linking, contrasted to the primarily ID/IDREF oriented hypermedia linking model in DocBook. I don't personally find myself able to "Leave it all to the editing platform," either -- my not being able to assume any manner of an opacity about the DITA markup format -- as I'm fairly certain that I may be editing a DITA markup file in a console-based text editor, at some point in time.
So, although those features of the DITA markup schemas may be such that I may find difficult to understand -- at least, at either of a first or second approach, in study -- now that I've found more of a friendly documentation about DITA and reviewed a couple of DITA document source trees, I'm fairly certain that I should be able to learn to proactively adapt my own hypermedia knowledge to adjust to the DITA document formats, even inasmuch as with regards to extending DITA.
It's on that note, then, that I am still trying to write around the "Long leap" of the following tasks, as I can forsee in my own "Next nine yards" about DITA:
- Installing Java on my own FreeBSD notebook, with work-log, notes, and documentation references correspondingly
- Installing the DITA Open Tooolkit Tools onto the same notebook, likewise with a set of corresponding notes and references
- Likely beginning at least a local project for creating a FreeBSD port of DITA Open Tooolkit. This task, ultimately may entail a communication and further coordination with the FreeBSD Java(R) Project. As such, it's nothing I may approach in any of a too casual regards. Not to say overmuch about my own opinions of Oracle's style in commerce or software development -- however contrasted to the novel goodwill style of approach, as originally developed by Sun Microsystems -- I think Oracle's left me with a little bit of a bad impression, as to Oracle's position reportedly ever disfavoring developments in free/open source software (FOSS) namely in defense-oriented projects, and perhaps Oracle's own lack of information, as such, candidly.
The Oracle Java(R) launcher thing on Microsoft Windows 8.1 -- though it's cute, certainly -- it doesn't really change that impression, so much, not to my own point of view. Candidly, I still expect Oracle to be the monolithic corporation largely focused about a database platform, such that I've -- for a long time -- estimated of Oracle as a company. I don't think it makes any less of an Atlas-like shadow, with Oracle having acquired Sun. With Oracle now having demonstrated their own obvious lack of information with regards to FOSS and defense systems software, I might wish to trust Oracle to be moreover a Blind Atlas -- very worrisome, I think, worrisome if Oracle would set about to "Make New The Things."
So, knowing of a particular manner of a corporate monolith as such, looming up a little ways northward in California, and with some much of a knowledge of a broader world, I'm afraid I'm unable to join in the local Cool Team Parties. Even in avoiding any manner of a too locale-centric manner of a perspective about software development, but it still kind of "Creeps me out," about Java(R), if Oracle is really all the Enterprise as may I candidly estimate it to be.
If it may be possible to limit one's owns views to a sense of plainer principles, however -- inasmuch, to not make overmuch of a consideration as with regards to superstitions -- sure, Oracle might not be all of the scarily opaque commercial software institution that I might think of it as. Focusing if simply on the ongoing free/open source licensing of any products previously developed or adopted by Sun Microsystems -- such as Berkeley DB, for instance, in its free/open source licensing options -- there's a matter of software licensing, orthogonal to any company's own apparently political positions with regards to software development models.
Thus, there's a foot I can find, in my own sense of knowledge about software now licensed by Oracle -- a foot, at which I may be able to disembark from my own concerns with regards to Oracle's policies. If it could seem as though Oracle could become such as, "Like Old Microsoft, but a thousand times worse," there's what I'm worried about. Regardless, the free/open source licensed by Oracle as free/open source software, that much of software might endure any such shift -- as much as of any free/open software licensed originally by Sun Microsystems.
So, in something of a sense of an organizational view, maybe the goodwill "Vibe" that Sun developed could be just enough that it may endure even the acquisition by Oracle -- however far any developers and managers who would've been the parties directly developing such goodwill, and about a programming language moreover, however far "The Java Original Team" in and beyond Sun, may have been put off and away from Oracle.
If I'd thought as though the film TRON: Legacy may have been all of a metaphor about Apple, perhaps it could as well be a film interpreted as if about any other Silicon Valley empire of an enterprise -- Oracle, perhaps as like a CLU character nearly making Java break out so much that it would break apart?
I don't find myself able to ignore the apparent social implications of Sun's acquisition by Oracle -- it seeming even more worrisome, after Oracle tried to toss some mud to the US DoD, as denoted in an article once reported to Slashdot, mud as if about free open source software. The "Old Microsoft 2.o?" theme, thusly, it began in my own simple point of view about Oracle.
Clearly, Oracle "Owns" Java(R) as a trademark, today, but -- not even after the acquisition of Sun -- Oracle certainly does not own the history of the Java programming language. Thus, there's a broader sense of context, and nothing radical, about not looking too far into the Oracle.
So, maybe there's any plan for Java integration in LLVM. I'll have some research to develop, before I myself may develop any further work about Java(R) on a FreeBSD(R) operating system. The Brand Wars not begun again, they have not.
No comments:
Post a Comment