[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Meeting minutes
|
Hello,
Please find below a summary of today’s discussion:
I. Administration.
Attendance: Yoshito, Rodolfo, Lucía, Bryan. We have quorum.
L: I move to approve 20th July meeting minutes.
https://lists.oasis-open.org/archives/xliff/202108/msg00000.html
Do I have a second?
R: I second.
L: Meeting minutes approved.
R: [Rodolfo shares his screen and shows the specification (core only) with the new style of OASIS.]
B: We can rename this, and this can be called “Core” and “Extended”.
R: I was looking at what DITA did. So we can one just core and one “full” or “extended” that will contain the modules.
B: I like this idea, I am glad that is coming into fruition.
R:I have a few issues with the core. For example, we have one section “declare XML namespaces” with the modules namespaces.
L: We might need an explanation explaining what we have implemented: core and the extended version, and add a hyperlink to the extended version for people who want to use it.
R: We have other issues, like broken links pointing to ITS or matches. We will need to do some annotations to explain this.
L: I think we need these clarifications and the links to the extended versions.
B: I agree.
R: There are only ten cases where will have these issues. There are not that much. We can just add a note.
B: what is the value of having these mentions in the core?
R: Little, for example, here is one that refers to the schematron use in one of the modules.
B: If our goal is to educate the readers to say there are extended capabilities, we need to have the notes. But if these notes are just to include information that is not that relevant,
they might be more harmful/confusing than helpful.
R: I agree
L: Me too.
R: Some years ago, I did some work on creating a merger that allows me to merge all the xml files of the spec into a single one. OASIS has changed the style. I need to rewrite the merger
and adjust it. We also have an updated docbock spec. We have a customised version of docbook. So it means that I need to make other changes to the XML. Producing the ISO compatible version might be very complicated.
L: I think that the question about ISO is better to be addressed to David.
B: Yes, David and Peter were the ones working on the ISO liaison.
R: Peter is still a member of our committee.
R: I am not sure we can generate an OASIS standard, it would be easier to publish the committee specification.
B: I think the requirements have changed slightly. I think it would be worth to fight to do that. I have a widely experience with it, that would be a contribution that I would be happy
to do.
R: That is fine. I do not mind reusing this docbock formatting. It would be the same thing to create an OASIS standard or committee speciation, but doing the ISO implies bigger changes,
it is not so easy. We need to see if we have the manpower to do it or not.
B: I think you were talking committee vs OASIS, not ISO.
R: Anyone with an XML editor can produce an OASIS or committee spec. To do the ISO we would need extra efforts and permissions to include the information in a server, etc..
R: If you agree, I can start drafting, I would need to know how to name the two specs.
L: I think Bryan as native speaker can help us to use the best term for the extended version.
B: My preference would be to call them “core” and “extended”. I think “full” can have other implications.
R: Ok.
R: This documentation lives in Github. I do not know if you have the rights to review or write.
L: I will have to check that.
R: I do not if you want to suggest a change, we can do it by sending an email to the mailing list.
Y: I think github has a function to have the final html, that can be helpful for people to contribute.
R: this is the github repository. We do not have a publishing engine for github. We need to merge all the elements, once we have the full xml, we apply stylesheets using oxygen to produce
the html version. There are a couple of transformations: merge and apply the stylesheet. There is also another stylesheet .fo and we need render that produces the pdf.
L: Have you produced the pdf of just the core to know how many pages does it have?
R: the core has 76 pages. And the extended has more than double (186).
L: that is really good news.
R: The table of contents, is much smaller. Yoshito are you using the ITS module?
Y: No, I do not.
R: We are going to use the stylesheets from oasis for this.
R: I receive emails when somebody publish in github.
L: do you have a specific plan on how to proceed?
R: I do not have a plan, you can have a look at the files and send an email to the mailing list. Timeline I do not because I do not know what would be need. We might need to make
a list and set a deadline.
R: I will send an email today.
Y: In general, we can to use the github issue request. We need to agree on the items that need be worked on for 2.2. We can issue them and based on what we will have on that list,
we can set objectives and have a deadline set.
L: I agree, thanks Yoshito.
R: I agree too.
B. Migration guide & Online Validation Tool. Feedback, next steps.
https://lists.oasis-open.org/archives/xliff/202101/msg00002.html
R:Are you still using the validator?
Y: Not regularly. Is this the same code you have on github?
R: Yes, this is the same code.
R: there were two publications from messageformat (one based on trees and another on lists), but nothing concrete on how to represent XLIFF so far. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]