RE: [dita] DITA 1.1 issue 20: Extensible metadata attributes

["Esrig, Bruce (Bruce)" <esrig@lucent.com>]

A third alternative would be to externalize the metadata values during generalization so that a single attribute such as otherprops doesn't have to carry around a huge burden of additional data.

 

If it were practical to support in editing and storage tools, the architecture could make an external metadata database a permanent feature. Metadata would be externally referenced in ordinary instances as well as during processing.

 

Best wishes,

 

Bruce Esrig

 

==============

 

Train of thought ...

 

How much metadata is there? A many-to-one mapping of attribute values would run a risk of overflow if there are any limits on the size of an attribute value.

 

The values for some metadata attributes may be large. It's conceivable that some would choose to represent a product hierarchy in a single value, by providing internal punctuation to delimit a cascade of category and subcategory names. Also, there may be a lot of metadata attributes. We have around 20 metadata attributes on a short list, and more on a wish list. The limitation is that we're not sure we can populate a meaningful proportion of the values.

 

If there are limits on the total size of attribute values, then a many-to-one mapping would not impose a radical new limitation. Also, if very few values are large, combining them might still work.

 

A third alternative is to externalize the metadata. A method of indirection could be defined for retrieving the metadata for an element. This would work provided that metadata dereferencing does not become a burden. To search on the metadata, it would be necessary to maintain a normalized version that dereferences the metadata or else search the metadata in the external location and trace back to the element from any results that match.

-----Original Message-----
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Wednesday, June 01, 2005 9:17 PM
To: Paul Grosso
Cc: DITA TC list
Subject: RE: [dita] DITA 1.1 issue 20: Extensible metadata attributes

One of the issues is how to preserve the attribute values during generalization, and potentially during respecialization as well. For new elements, you can generalize and respecialize by preserving ancestry in the class attribute.  Another issue is how to compare allowed metadata during conref: for example, to ensure that you are not pulling content with metadata into a topic where that metadata is invalid.

A possible solution could be to store the metadata attribute values in the otherprops attribute during generalization, and track which metadata attributes are in use by adding the names of the attributes to the list of used domains (in the domains attribute).

For example:


original:
<topic id="blat" domains="(topic ui-d) a(otherprops proglang)">
...
<p proglang="Java">...</p>
</topic>

generalized (with roundtripping intent):
<topic id="blat" domains="(topic ui-d) a(otherprops proglang)">
...
<p otherprops="proglang(Java)">...</p>
</topic>

Michael Priestley
mpriestl@ca.ibm.com

"Paul Grosso" <pgrosso@arbortext.com>

06/01/2005 06:24 PM

To	"DITA TC list" <dita@lists.oasis-open.org>
cc
Subject	RE: [dita] DITA 1.1 issue 20: Extensible metadata attributes

I haven't thought a lot about this yet, but I was having
a discussion with some of our developers today who also
felt the need for extensible metadata attributes, and
they felt the right way to do it was to have a separate
namespace for metadata attributes.  

Then the DITA schema could allow any attribute in
that namespace on any element, so it would be easy
to add "profiling" attributes or other metadata.

paul

> -----Original Message-----
> From: Christopher Wong [mailto:cwong@idiominc.com]
> Sent: Wednesday, 01 June, 2005 17:15
> To: DITA TC list
> Subject: [dita] DITA 1.1 issue 20: Extensible metadata attributes
>
> Could I get an idea from our XML gurus how this could be
> achieved in a
> compatible manner? The issues list does not quite have a lot
> of details.