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:]
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
"Paul Grosso"
<>
06/01/2005 06:24 PM
To
"DITA TC list"
<>
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:]
> 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.
