bibdata refactor changes

[opoudjis]

The following changes impact this gem, as elements moved to bibdata/ext from bibitem. All elements specific to ISO must be populated in bibdata/ext; please ask me if there are any changes not covered in the following.

The grammar of ext is:

BibDataExtensionType =
        doctype?, editorialgroup, ics*, structuredidentifier

editorialgroup = element editorialgroup {
  technical-committee+, subcommittee*, workgroup*, secretariat?
}

technical-committee =
  element technical-committee { IsoWorkgroup }

subcommittee =
  element subcommittee { IsoWorkgroup }

workgroup =
  element workgroup { IsoWorkgroup }

IsoWorkgroup =
    attribute number { xsd:int }?,
    attribute type { text }?,
    text

secretariat =
  element secretariat { text }

ics = element ics {
  element code { text },
  element text { text }
}

structuredidentifier =
  element structuredidentifier {
    attribute type { text }?,
    (documentnumber, tc-documentnumber? )
}

DocumentType =
     "international-standard" | "technical-specification" |
     "technical-report" | "publicly-available-specification" |
    "international-workshop-agreement" | "guide"

• The type of standard, e.g. "international-standard", is no longer set in bibitem/@type. It is now set in bibdata/ext/doctype

• title-main is replaced with title[@type = 'title-main']. The lang attribute is retained.

• title-intro is replaced with title[@type = 'title-intro']. The lang attribute is retained.

• title-part is replaced with title[@type = 'title-part']. The lang attribute is retained.

• A title[@type = 'main'] shall be added, consisting of title-main, title-intro, title-part, joined by space-endash-space. The lang attribute is retained.

• editorialgroup moves to bibdata/ext.

• ics moves to bibdata/ext.

• The structured ISO identifier, using project-number and part-number attributes, is moved from bibitem/docidentifier to bibdata/ext/structuredidentifier. In bibitem/docidentifier, the ISO identifier given should be the identifier as it appears on the site, with the part numbers incorporated; e.g. <docidentifier type="ISO">ISO 631-1</docidentifier> vs <structuredidentifier><project-number part="1">ISO 631</project-number></structuredidentifier>

[opoudjis]

For all of these, let me know if you need XML samples; the easiest thing to do is to change the spec examples.

[andrew2net]

@opoudjis was the status moved to the BubliographicItem class?

[opoudjis]

The status is in bibitem, and there is therefore no validation of its vocabulary by enum any more in the grammar: that is flavour-specific, and it is done in the consuming gems for bibdata.

[andrew2net]

@opoudjis there is a /bibitem/note element in IsoBibliographicItem. We pass the content of the element as an argument of to_xml function. In isostandard.rnc grammar there is a definition of the biblionote which could have type and reference. Should we be able to pass type and reference to to_xml function?

[opoudjis]

Ah. I was wondering about that.

biblionote now already has the type attribute in relaton; so the type attribute must be passed in.

The reference attribute is an error: I'm removing it. I had it in there because ISO bibliographies are rendered with footnotes, if there is a draft reference. But the footnote is inserted at the isodoc level, if it detects a note entry at all: the footnote is not present in Metanorma XML.

[andrew2net]

@opoudjis if pass a note argument to to_xml function we get an xml with /bibitem/note element. Should we parse the element when create IsoBibliographicItem from xml?

[opoudjis]

I do not understand the question. Note is correctly parsed in bibitem, and isobib does not change anything about it, now that I have removed the spurious reference attribute.

[andrew2net]

@opoudjis in IsoBibliographicItem we pass note ooption in to_xml function, not in constructor:

    def render_xml(builder, **opts)
      builder.send("iso-standard", xml_attrs(type)) do
        ...
        if opts[:note]
          builder.note("ISO DATE: #{opts[:note]}", format: 'text/plain')
        end
       ...

so it doesn't save the option in the model. Should we change the behavior?

[opoudjis]

Ah. I can see why that's done, and why we would want to inject a note into the reference. Preserve this behaviour: any note included in the options should be added to any notes already included in the screenscraped reference. However any such injected notes are an ad hoc operation by the calling routine: the added notes should not be included in the cached XML.

The user should also have the option of including a type for their note, although I can see that would get awkward. It would also be nice to allow there to be multiple notes added by the user, as an optional array.

[ronaldtse]

Just to be clear, we want to accept personal notes in Relaton XML/YAML right? This was Relaton can be used in bibliographic managers.

[opoudjis]

You can inject notes; I'm just saying it won't cache them, because the calling client could be inserting a note for any number of transitory reasons. And if your client is a bib manager, surely it doesn't need to cache, because it is storing the results itself.