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
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.