profiling attributes for TEI?

[Ron Van den Branden]

Hi,

I'm trying to define a document type association for a TEI P4-based customization. One of the things I'm looking for is creating (open-ended) suggestion lists for attribute values. Unfortunately, I'm no Java head so I'm afraid the really cool things are out of my reach (I'd like, e.g. to construct such a list by looking up with XQuery what values are already present for an attribute, so that this system could 'learn' as the document base is expanded, in a minimal way).

I figure the "profiling/conditional text" feature comes closest to implementing such an attribute value suggestion list. I've tested by successfully toying with the DITA and DocBook samples; yet I can't get it working for the TEI document type. While I manage to successfully define a profiling attribute by specifying values for the global @n attribute, these don't show up when trying to add an @n attribute in author view: the suggestion list for the values remains empty.

Is more needed to enable this feature for TEI, or doesn't TEI support profiling attributes (I only learned through Oxygen that it seems to be a feature of DITA and DocBook)? If so, is there another way to enable such an autosuggestion feature for attribute values (I'm using a DTD, so I don't think there's a way to define open-ended lists via the DTD)?

Kind regards,

Ron

[Radu]

Hi Ron,

The attribute values defined in the Editor / Pages / Author / Profiling/Conditional Text preferences page can be used by default in the Author page when using the Editing Profiling Attributes... contextual menu action.

For DITA and Docbook these attribute values can also be accessed in the Attributes view but this was done by using some special framework Java API customization which was not implemented for TEI.

But from what I understand you want to learn the values for a certain attribute from the document and then propose them in the Attributes view.

This can be done using our Java based Author SDK:
http://www.oxygenxml.com/developer.html ... horing_SDK

Basically you would have to implement a ro.sync.contentcompletion.xml.SchemaManagerFilter which would allow you to add more attribute values for certain attribute.

If you are comfortable with Java and would like to try this approach I could try to give you more details.

Regards,
Radu

[Ron Van den Branden]

Hi Radu,

Thanks for your suggestions.

For DITA and Docbook these attribute values can also be accessed in the Attributes view but this was done by using some special framework Java API customization which was not implemented for TEI.

That's what I suspected... I guessed that I was trying to 'abuse' the profiling system to get suggestion lists for attribute values in the Attributes view anyway. IIRC, those can be achieved without much problems by using a schema language other than DTD, but unfortunately I have to stick to the latter, where the only possiblility is to hard-code attribute values as an exhaustive list in the DTD itself. Which wouldn't allow for any other values than the predefined ones.

If you are comfortable with Java and would like to try this approach I could try to give you more details.

Sounds great; I've downloaded the Author SDK and read the author developer guide, but unfortunately have no 'active' Java knowledge. Unless there's a walktrough for dummies available?

Kind regards,

Ron

[Radu]

Hi Ron,

You need some knowledge of the Java programming language to write extensions for Oxygen.
Maybe if you give a clear example about what attribute values should be collected and where they should be presented (on the same attribute name or on a reference attribute) I could try to give you some source code which would work with Oxygen 12.2.

Regards,
Radu

[Ron Van den Branden]

Hi Radu,

Thank you very much for your helpful offer. I'll try to illustrate my wish list as clearly as possible. I would like to offer our encoders some assistance in disambiguating proper names. Currently (using TEI P4), we're tagging them as <name> elements, and using the @reg attribute for this purpose, which holds the normalised string value of the name. But ideally, we'd want to switch that to the @key attribute, pointing towards an external list of identified persons, events, places, books, articles,.... Those are encoded in an external XML file, in <div>s with a @type corresponding to the <name>'s @type attribute. For example:

Code: Select all

<div>

  <div type="event">

    <div id="expo1958">

      <head>World Expo 1958</head>

      <p><!-- description --></p>

    </div>

	<!-- ... -->

  </div>

  <div type="person">

    <div id="EP001">

      <head>Elvis Presley</head>

      <p><!-- description --></p>

    </div>

	<!-- ... -->

  </div>

  <!-- ... -->

</div>

So, for example: when editing the @reg attribute for a <name type="event"> element, it would be great if Oxygen could scan other documents (either in a certain location or an eXist db), retrieve all distinct values for other @reg attributes of <name> elements with a matching @type attribute, and offer those as a suggestion list. Or, when entering a @key attribute for a <name type="person"> element that should be linked to the "EP001" element in the external document (say, keys.xml), Oxygen could scan the list of @id values for those <div> elements inside a container <div> whose @type value matches that of the element being edited (in this case: 'person'), and offer them as a suggestion list.

In short, I see 2 possible requirements:
-for the @reg attribute: scan a collection of other XML documents (either on the filesystem or in an eXist db, whatever is possible) for distinct values of the @reg attributes inside names (of the same @type), and offer these when entering a @reg attribute
-for the @key attribute: scan another XML file, retrieve all @id values for <div> elements with a matching @type value and offer these when entering a @key attribute

Do you think that's possible?

Kind regards,

Ron

[Radu]

Hi Ron,

This can be done by implementing a SchemaManagerFilter and adding the implementation as an extension in the TEI P4 document type but you need to find someone with fair knowledge of Java (and of parsing XML files with Java libraries as you need also to gather values from those XML files).

We do not do such customizations ourselves but if you find a Java developer we could guide him if he encounters any problems during the implementation.

Code: Select all

package ro.sync.sample;



import java.util.List;



import ro.sync.contentcompletion.xml.CIAttribute;

import ro.sync.contentcompletion.xml.CIElement;

import ro.sync.contentcompletion.xml.CIValue;

import ro.sync.contentcompletion.xml.Context;

import ro.sync.contentcompletion.xml.SchemaManagerFilter;

import ro.sync.contentcompletion.xml.WhatAttributesCanGoHereContext;

import ro.sync.contentcompletion.xml.WhatElementsCanGoHereContext;

import ro.sync.contentcompletion.xml.WhatPossibleValuesHasAttributeContext;

import ro.sync.outline.xml.Attribute;



public class TEISchemaManagerFilter implements SchemaManagerFilter {



	@Override

	public List<CIValue> filterAttributeValues(List<CIValue> values,

			WhatPossibleValuesHasAttributeContext attrsContext) {

		if(attrsContext.getGrandparentElement().equals("name")) {

			//The value of the "@type" attribute.

			String type = null;

			List<Attribute> previousAttributesList = attrsContext.getPreviousAttributesList();

			if(previousAttributesList != null) {

				for (int i = 0; i < previousAttributesList.size(); i++) {

					if("type".equals(previousAttributesList.get(i).getLocalName())) {

						type = previousAttributesList.get(i).getValue();

					}

				}

			}

			if("reg".equals(attrsContext.getAttributeName())) {

				//TODO Get values for the "@reg" attribute, the type is already known.

				//Scan the XML files and gather all values for the known type. 

			} else if("key ".equals(attrsContext.getAttributeName())) {

				//TODO Get values for the "@key" attribute, the type is already known.

				//Scan the XML files and gather all values for the known type.

			}

		}

		return values;

	}



	@Override

	public List<CIAttribute> filterAttributes(List<CIAttribute> arg0,

			WhatAttributesCanGoHereContext arg1) {

		return arg0;

	}



	@Override

	public List<CIValue> filterElementValues(List<CIValue> arg0, Context arg1) {

		return arg0;

	}



	@Override

	public List<CIElement> filterElements(List<CIElement> arg0,

			WhatElementsCanGoHereContext arg1) {

		return arg0;

	}



	@Override

	public String getDescription() {

		return "Schema manager filter";

	}

}

Regards,
Radu