Has anyone implement DITA 1.2 Subject scheme in their work? - dita

I would like to know if there is anyone who has implemented the subjectscheme maps of DITA1.2 in their work? If yes, can you please break-up the example to show:
how to do it?
when not to use it?
I am aware of the theory behind it, but I am yet to implement the same and I wanted to know if there are things I must keep in mind during the planning and implementation phase.

An example is here:
How to use DITA subjectSchemes?
The DITA 1.2 spec also has a good example (3.1.5.1.1).
What you can currently do with subject scheme maps is:
define a taxonomy
bind the taxonomy to a profiling or flagging attribute, so that it the attribute only takes a value that you have defined
filter or flag elements that have a defined value with a DITAVAL file.
Advantage 1: Since you have a taxonomy, filtering a parent value also filters its children, which is convenient.
Advantage 2: You can fully define and thus control the list of values, which prevents tag bloat.
Advantage 3: You can reuse the subject scheme map in many topic maps, in the usual modular DITA way, so you can apply the same taxonomies anywhere.
These appear to be the main uses for a subject scheme map at present.
The only disadvantages I have found is that I can think of other hypothetical uses for subject scheme maps such as faceted browsing, but I don't think any implementation exists. The DITA-OT doesn't have anything like that yet anyway.

Related

Template Toolkit: Extracting a part of a template

I was assigned the task to rewrite our home-made templates with Perl Template Toolkit.
Our templates have the possibility to extract a fragment of the template (and then make HTML from it) instead of using the entire template.
How to do it with Template Toolkit?
The best solution I came with is the following:
Let we have a template x.html with fragment A.
The fragment should be extracted into new file. (I am to name it like x/A.html for consistency.) In the original template x.html it should be replaced with [% INCLUDE 'x/A.html' %]. So I could be able to use either the entire template x.html or its fragment x/A.html. Probably we may have several levels of inclusion like x/A/B.html.
Are there other ways to do it? (I don't like to idea to split it in subdirectories as described above, but haven't come up with a better solution.)
Are you asking whether there's a better way to extract the fragment from the parent template?
(Answer is: no, that's probably the best way.)
Or are you asking is there a better way to organize the extracted fragements?
(Answer is: no real best answer, everywhere will have their own house style - you aren't going to go too far wrong by picking any convention.)
Most common conventions for naming I've seen are subdirectories x/A.html and prefixes x_A.html. Whether you use the name of the parent template for x or you choose to group by functionality as simbabque suggested is another matter of taste: grouping by functionality scales better on larger and more complicated layouts where you have a great deal of reuse of components, but grouping by use case is conceptually simpler in smaller use cases with little or no component reuse.

EAnnotation usage in ecore

Can anybody explain the usage of EAnnotation in ecore, in terms of its specific fields (i.e.,
Source,
Details,
EModel Element,
Contents, and
References). I looked at its API documentation here, but could not get that much from there.
I am looking for a kind of guideline to explain by example what are the purpose of having annotations with such fields in ecore.
I asked this question in Eclipse EMF forum and here is an answer.
There is also an answer to this question here..
However, I briefly provide an answer to this question:
Generally EAnnotations are used in Ecore to encode any kind of information which is not captured by Ecore at first place. For example, they are used in OCLInECore to hold OCL constraints, or in genmodel to store code generation related information and etc.
Source is used to identify the type of annotation. It is usually populated with a URI, to uniquely identify the type of annotation.
Details is a set of (key,value) pairs to hold detailed information regarding this annotation. Actually this is the place annotation data are really stored.
The rest is (quoted from here):
EModel Element ,
"An EAnnotation is itself an EModelElement, so can also be annotated. It's not
often used, but would allow you to build a complex structure.."
Contents
EAnnotations can contain arbitrary other objects. This is also not
often used, and if you do use it, you can't generate a normal
XyzPackageImpl but must ensure that the GenPackage specifies "Initialize
by Loading"..."
References.
"EAnnotations can refer to arbitrary other objects. This is also not
often used, and the same caveat applies and for the contents..."

How to do a new extension with Schema.org + Microdata?

I have seen in a post that the slash is no longer up to date for creating new extensions in Schema.org.
I am using Microdata and would prefer to stick to it across my site.
What is the new way to create a new extension?
For example I want to create a new extension for MedicalTourism under the category Travel Agency. Before it would have been
http://schema.org/TravelAgency/MedicalTourism
What is the new way?
And what would the code look like?
You may still use Schema.org’s "slash-based" extension mechanism. It’s "outdated", but not invalid.
But it’s not (and never was) a good idea to use this mechanism if you want other consumers to understand or make special use of your extensions.
In some cases you could use Schema.org’s Role type, which allows you to give some additional data about a property, but not about types.
Alternatives
Propose new types/properties: If they are useful and the sponsors agree, they might get added to the Schema.org vocabulary at some point.
Use an existing vocabulary that defines types/properties for your use case (or create a new vocabulary if you don’t find one):
Either instead of Schema.org,
or in addition to Schema.org (while this works nicely with RDFa, Microdata is pretty limited: you’d have to use Schema.org’s additionalType property for additional types and full URIs for additional properties).

CMFWorkflow and Marker Interfaces

I'm currently prototyping a small project in Plone and trying to KISS as much as possible while the requirements are still in flux. To that end, I've resisted creating any custom content types for now and have been using marker interfaces to distinguish between "types" of content.
Now that I'm looking at workflow, I've realised that they're bound to types, and there doesn't seem to be a mechanism for assigning them to markers. I think I could wrap portal_workflow with my own version that looks for markers and returns the appropriate workflow if found, however, this doesn't feel like a tenable approach.
Is there a way of assigning workflow to markers that I've missed, or should I just bite the bullet and create some lightweight custom content types instead?
There's not really a built-in feature to use markers, but at http://www.martinaspeli.net/articles/dcworkflows-hidden-gems, Martin Aspeli hints that it is possible:
Note that in Plone, the workflow chain of an object is looked up by
multi-adapting the object and the workflow to the IWorkflowChain
interface. The adapter factory should return a tuple of string
workflow names (IWorkflowChain is a specialisation of IReadSequence,
i.e. a tuple). The default obviously looks at the mappings in the
portal_workflow tool, but it is possible to override the mapping, e.g.
in resopnse to some marker interface.

Basic principle of auto complete

How do they perform auto complete of code in eclipse or other ides? What is basic principle behind it?
You know how you have to explicitly attach source code to non-standard libraries you imported in Eclipse? When you do that, text-search index is built over that source and this way IDE knows to offer you auto-complete feature. Roughly, I suppose it is something as associative array where key is the prefix of method you typed, and value is description of that method.
Now what is important for this functionality is to be implemented efficiently regarding both time and memory consumption. It would be very inefficient to store the same entry for every possible prefix of some method. (Or even to store every prefix!)
One of interesting structures that could be suitable for this problem is Trie, which is inherently optimized for prefix search while keeping acceptable memory usage.
Take a look here for a simple example:
http://www.sarathlakshman.com/2011/03/03/implementing-autocomplete-with-trie-data-structure/
Besides Tries, used for the case when you have already typed the beginning of the name of a method/var, I think it also uses some sort of type comparison/analysis for the case when you try to invoke a method and the IDE suggests you a local/global variable to pass as parameter to that method call.