-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PubID creation for Stages and Amendments #102
Comments
Please add these cases to the RSpec tests. |
"year" is an edition here, it will generate "ISO 17301-1:2016" as a base document id. |
@mico what I mean is, without an edition, there cannot be an amendment URN. When there is no edition number, it is possible to create a PubID in string. However, RFC 5141 URNs for amendments require existence of an edition number. Therefore an error should be raised. |
Already have test for that https://github.com/metanorma/pubid-iso/blob/main/spec/pubid_iso/identifier_spec.rb#L868 |
@ronaldtse We have PubID identifiers with edition included in PubID, examples:
Now we also include edition to generated PubID when we have one of these identifiers as input.
Where edition is not included in PubID output but included to URN. |
Good point @mico. Can we provide a PubID rendering option to whether show Edition or not? |
We have been generating undated identifiers for all ISO documents, including amendments. So both ISO 123:2001 and ISO 123, and therefore both ISO 123:2001/Amd 1:2002 and ISO 123/Amd 1. However, I don't think you are wrong in raising this error. ISO 123 is much more meaningful than ISO 123/Amd 1 is: ISO 123 refers to the set of all editions of ISO 123; ISO 123/Amd 1 is much less well-defined. So for now, I'm going to not generate undated identifiers for amendments. @ronaldtse @Intelligent2013 let me know if this raises concerns. |
Yes this error is correct indeed. We are now disallowing the PubID "ISO 123/Amd 1" because a supplement must be based on a base publication with either edition of year. We should not generate undated identifiers for amendments. |
@ronaldtse we already have this option (with_edition):
but without this option, result will be:
Is it enough for now or we should change something? |
Lots of minor discrepancies between what I'd implemented and the current code, now that I have the code working. Posting to confirm: Before:
Before
Before:
Before:
Before:
|
This is a question to be discussed in #76
This is correct.
Correct. "Cor." is legacy practice that has been replaced with "Cor" (no period).
Correct. Iteration is after the document/part number prefixed with the full stop.
This is wrong. It should have been "ISO/WD 1000-1.3".
This is correct. The previous
This is usage dependent:
This means we need to have some option of specifying behavior here. |
I would still rather we be able to specify stage as numbers rather than codes; as it is, the stage parameters are abstract anyway (we specify "FDIS" to get "FDTS" for tech specs, so we might as well just specify "50".) OK, a couple of things to fix still, but this is substantially improved. |
Can we reverse the default behavior i.e. |
I agree that we should also allow specifying stages via stage codes (and substage codes). When using it though understand that there will be inconsistencies: stage codes for PRF and FDIS are identical, so anything 50.00 will be rendered by default as FDIS unless you specify the PRF stage. (@mico can you put this in the README? Thanks.) |
Because the pubid-iso gem is now going to act as my oracle for stage abbreviations (why should the lookup tables for abbreviations be implemented twice?), I will need to be able to look up the actual abbreviation for a stage, as applied to the particular document type. So if the style FDIS is applied to a TS document, I need a function that will return me "FDTS" given the initialised identifier. id.stage.abbr still returns me "FDIS". I request it be updated to return FTDS. Similarly, I'd like for it to return "IS" for 60.60, even though we suppress display of the "IS" stage identifier. This will allow me to remove my own mapping to stage abbreviations, so that there is only one source of truth for abbreviations. |
Pubid::Iso::Identifier.new(**{:number=>"1000", :language=>"en", :type=>"DIR", :publisher=>"ISO", :copublisher=>[], :urn_stage=>"60.60"}).to_s(with_language_code: :single) outputs "ISO DIR 1000" and not the expected "ISO DIR 1000(E)" |
But note that this entire venture was triggered by metanorma/metanorma-iso#657 :
|
We don't have DIR documents with language code. (https://github.com/metanorma/pubid-iso/blob/main/spec/fixtures/iso-pubid-directives.txt) |
See this, this is correct behavior:
@mico sure, let's support DIR with language codes as well. Thanks. |
@opoudjis I need a bit more context here. The return value requested is inconsistent in these two cases:
Maybe the "doctype + stage" abbreviation can be called the "document number prefix", but notice that there is a challenge:
What should these return? Unless you include the "ISO..." bit the values will be inconsistent. |
At the moment, these are being shoved into ISO/TR => "TR" .... I don't see that consistency is that important. I think it is far more important that we not destroy a PDF workflow that has been stable for the past two years out of pedantry. I also don't particularly see where else this information should be stored: it is a stage abbreviation, albeit specific to a document type. So? If your concern is what pubid-iso calls this, as opposed to what Metanorma XML does with it: what pubid-iso calls this data element of course is up to pubid-iso, as long as I can obtain it to pass it on. You can call it type_stage_abbrev if you like. The inconsistency just means it is specific to the type/stage combination, but that does not impact anything in identifier generation anyway. I just want the string, so that Alex can put the string in the PDF front cover. |
This inconsistency is a real issue because it impacts @Intelligent2013 as well. The PDF workflow should not need to manually reconstruct these prefixes. What I am stating here is: the publisher, document type and stage abbreviations are LINKED and dependent on each other. They need to be represented as one string. Ping @Intelligent2013 on how this works for you? |
I don't clear understand the changes. I.e. |
The text representation of abbreviation XSLT reads from <stage abbreviation="DIS" language="en">Draft International Standard</stage> |
You are completely misunderstanding the requirement, @ronaldtse. This is nothing to do with document identifiers. I am providing the stage abbreviation, for him (and me) to display on the coverpage for unpublished documents: IT SAYS, on the cover, "FDTR stage" in the warning box. That string is unlinked to the publisher and the document type: this is not the document identifier. I am asking for this gem to provide me that abbreviation, so I don't have to reconstruct it myself any more, and maintain a separate source of truth on those type-specific stage abbreviations. |
I still need the stage output. Moreover, whatever the incompatibility is between pubid-iso and relaton-iso needs to be resolved. relaton/relaton-iso@5b6a684 @andrew2net This is now holding up tomorrow's release. The stage output, I can wait on. The incompatibility between pubid-iso and relaton-iso, I cannot. |
@opoudjis thanks for the explanation. We could provide the "FDTR" abbreviation and full name for a pubid. The same happens for TR, PAS. How about |
@mico can we implement this soon? thanks. |
The remaining issues have been dealt with by using the TypedStages concept. Once pubid-iso is released this can be used by relaton-iso. |
Closing this. |
These use cases have to work. All of them don't work -- I am merely typing out the expected output.
Case 1
Case 2
Case 3
Case 4
Case 5
Case 6
Task list
Identifier
#100The text was updated successfully, but these errors were encountered: