Re: [niso-sts] Semantic cardinality of metadata elements

["Imsieke, Gerrit, le-tex gerrit.imsieke@xxxxxxxxx" <niso-sts-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Ken,

See some thoughts below...

On 25.01.2022 19:59, G. Ken Holman g.ken.holman@xxxxxxxxx wrote:
> 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:
> > B The following, in order:
> > B  <iso-meta> ISO Metadata
> > B  <reg-meta> Regional-body Metadata, zero or one
> > B  <nat-meta> National-body Metadata, zero or more
> > B The following, in order:
> > B  <reg-meta> Regional-body Metadata, zero or one
> > B  <nat-meta> National-body Metadata, zero or more
> > B <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:
>
>  B  <std-meta std-meta-type="international">
>
> and:
>
>  B  <std-meta std-meta-type="european">
>
> and:
>
>  B  <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>?

This would be a non-backwards compatible change wrt NISO STS 1.0. We are 
currently planning to keep the next NISO STS version backwards 
compatible. That is, we cannot immediately reduce the max cardinality to 
one.

It is likely that in the next non-backwards compatible version, 
iso-meta, reg-meta, and nat-meta will be removed altogether, and the 
number of std-meta elements in standard/front will be one at most.

As an aside: Co-published standards or adoptions where each organization 
has their own document numbers etc. could be an argument in favor of 
multiple std-meta elements at a given adoption level. In std-org-group, 
there is a provision for multiple publishers/SDOs, but these 
organizations need to share all other metadata of the std-ref element 
they're in. So multiple std-meta elements at a given nesting level could 
be a solution to this, but, as you noticed, adoption/adoption-front 
doesn't allow multiple std-meta elements. The overall standard number is 
often a shared one for co-published standards, but there are also 
organization-specific identifiers, classification data, etc. that are 
different. For these, an originator attribute may already be used on 
many elements that are allowed within std-meta. But maybe we need to 
document more explicitly that this originator attribute *should* 
correspond to the content of an std-org-abbrev element.

I donbt remember exactly the reason why we allowed std-meta multiple 
times in standard/front. We certainly anticipated that people would -- 
er -- adopt the adoption model rather than try to replace their 
nat-meta, reg-meta, and int-meta with multiple std-meta elements in 
/standard/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?

For std-doc-meta, precedence/override semantics have been specified, but 
not for std-meta vs. classic meta.

Maybe the reason for the liberal model that may lead to non-sensical 
combinations of these meta elements was "STS is enabling, not prescriptive".

As it says on the std-meta documentation:

* The model for <std-meta> should be enabling not enforcing. This means 
that organizations desiring tighter control will need to create a more 
restrictive subset or restrict content in another processing layer, for 
example, using Schematron.
* The new metadata model must not interfere with current ISO STS 
processing; any document valid to ISO STS 1.1 should still be valid to 
current NISO STS.

Of course we could have prohibited iso-meta etc. once std-meta was used 
in front while simultaneously adhering to these principles. Why we 
didn't do so escapes my recollection. Maybe the other NISO STS working 
group/standing committee members and especially Tommie or Debbie as the 
DTD authors can shine a light on this.

But it's a fringe case anyway and I've spent too much time on answering 
already. It's past midnight in Germany which means there's a new Wordle 
waiting to be solved.

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

My clients have started with NISO STS from scratch (or from their 
proprietary DTDs), but other SDOs such as Standards Austria or SFS have 
probably migrated from ISO STS 1.1, so maybe they can chime in, too.

Gerrit

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

--
Gerrit Imsieke
GeschC$ftsfC<hrer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit.imsieke@xxxxxxxxx, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

GeschC$ftsfC<hrer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt