> (2) Has this approach been widely adopted? (specifically in governments?)
> Note 1 of the document shows that some implementers prefer to represent
> the relationship within the metadata records rather than elsewhere. This
> is a logical preference given that it is simpler and more intuitive. Why
> are the two options in the presented not recommended? For example: The
> Government of Ontario (GO) Web Metadata Standard has a refinement of
> Contributor called Editor. In HTML it is expressed <meta
> name="dc.contributor.editor" content=""/>. This recommendation says that
XML attributes were intended mainly for metadata. Putting
data into them complicates things on several levels.
One problem with this approach is post-processing any XML. If
the attributes are reserved for out-of-band data it becomes
much easeir to include local metadata in the tags.
A structure like:
<foo:editor>
<type>dc.contributor</type>
<name>Jow Bloe</name>
</foo:editor>
is generally easier to process as an event stream (e.g.,
SAX) or extract twigs from. If I need to track editors
in SAX, for example, an "editor" hook can modify the
behavior of type and name easily; trying to add if-logic
to the editor handler to handle all of the attributes
and possible tag data over-complicates the code.
We use a few attributes to track sequence and
nesting in input data. Adding my own metadata to
an object whose data is in tags leaves the XML
more readable:
<foo:editor bar:seq="1">
<type>...
</foo:editor>
and simplifies the handling code.
As a separate issue, developing a useful schema
becomes harder as the number of attributes
containg data becomes larger. In partiuclar,
reuse of structural members gets difficult
becuase relating inherited collections of
attributes and tags becomes messy. If the
inheritence sticks to tags for data it's easier
to develop and extend.
> in XML it would be: <go:editor></go:editor>. This seems
> counter-intuitive because you are losing the fact that editor refines the
> DC element contributor.
<contributor>
<type>editor</type>
<name>Jow Bloe
</contributor>
What's lost?
Good example:
<dc:title>
<dcterms:alternative>foo</dcterms:alternative>
</dc:title>
Allows a single "alternateve" handler to deal
with alternative values, which can be toggled or
harvested in the title.
Trying to push this into
<dc:title dcterms:alternative="foo">
leaves you with "title" code that has to know
about alternatives. Given a large number of tags
that now have to handle alternatives in their
attributes, updating the logic for "alternative"
handling gets messier.
Another way to look at it is that the tags make
a nice encapsulation level for this kind of
optinal data.
--
Steven Lembark 117 E. 55th
Cognia NY, NY 10022
212 331 7844
|