Hi, all.
I'm working with NISO-STS and I'm looking at the metadata children of <front>.
The old ISO-STS was explicit in the cardinality of <iso-meta> and
<reg-meta> being zero or one:
https://www.iso.org/schema/isosts/v1.1/doc/index.html
Any one of:
The following, in order:
<iso-meta> ISO Metadata
<reg-meta> Regional-body Metadata, zero or one
<nat-meta> National-body Metadata, zero or more
The following, in order:
<reg-meta> Regional-body Metadata, zero or one
<nat-meta> National-body Metadata, zero or more
<nat-meta> National-body Metadata, one or more
Tying the front matter to the metadata was conveniently done through
matching originator="{value}" attributes, respectively, on <sec> and <*-meta>.
The new NISO-STS loosens this up, likely as a convenience for not
having the interleave semantic in the DTD schema language:
https://www.niso-sts.org/TagLibrary/niso-sts-TL-1-0-html/element/front.html
(std-meta | iso-meta | reg-meta | nat-meta)*
There is no discussion of semantic cardinality of these elements. Nor
about the mixing of them.
Out in the wild I see in separate documents:
<std-meta std-meta-type="international">
and:
<std-meta std-meta-type="european">
and:
<std-meta>
... but never more than one of those in the same document.
I am aware that the <adoption> model is a handy way (and the "right"
way) of associating front and back matter of adoption shells around
each other until the <standard> element at the core of the XML. Any
one <adoption> shell can have only one <std-meta>. Easy peasy, no
ambiguities in finding the associated front <sec> elements.
And, anyway, there is no originator= attribute on <std-meta> to use
for associating front matter sections.
But back to <standard> in NISO-STS ... am I to assume that the
semantic cardinality of <std-meta> under <front> is exclusive with
the other groups of metadata? This would make the front <sec>
elements unambiguously associated with the single <std-meta>.
But if not, do I assume front <sec> elements without originator= are
associated with <std-meta> and the others must have originator= to be
associated with their appropriate <*-meta>?
And if I am allowed to have two <std-meta> under <front>, how do I
distinguish which front <sec> elements are associated with which <std-meta>?
I think the max cardinality of one for <std-meta> in <adoption-front>
implies to me a max semantic cardinality of one for <std-meta> in
<front>, though this is not explicit.
I think the multiplicity of <nat-meta> in <front> in ISO-STS does not
translate to a multiplicity of <std-meta> in <front> in NISO-STS
because of the lack of originator= for <sec> in <front>. Just use
<adoption> in NISO-STS the way it was meant to be.
So the question for members of this mail list:
Would any user of NISO-STS challenge a system design decision
supporting a maximum cardinality of one for <std-meta> in <front>?
Would you then challenge <std-meta> being exclusive from any
occurrences of <iso-meta>, <reg-meta>, and <nat-meta>? If not, how
would you expect <std-meta> to be interpreted in the presence of a
sibling ISO-STS metadata construct?
Thank you for your thoughts on this. I would appreciate the
understanding of users in their expectations of migrating from
ISO-STS to NISO-STS. Am I making unnecessary work for myself trying
to support a hybrid because users simply will make the jump on their
own? What about users from different SDOs who are migrating on
different schedules?
. . . . . . Ken
--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/j/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @US$125 (5 hours free) |
Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |