OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Meeting minutes


Dear all,

 

Please find below a summary of yesterday’s discussion.

 

Best,

Lucía

 

 

----------------

Attendance: Mihai, Yoshito, Rodolfo, Lucía. We have quorum.

Administration

    Jan 16 meeting minutes - https://lists.oasis-open.org/archives/xliff/202401/msg00003.html

R: I move to approve the meeting minutes.

L: I second.

R: Meeting minutes approved.

 

Technical

    PGS module spec update status - https://github.com/oasis-tcs/xliff-xliff-22/issues/32 Mihai, Rodolfo.

 

[Rodolfo shares his screen and explains the latest changes on the spec]

R:I have changed Appendix A, because XLIFF is already registered in the IANA Media Types Registry.

Y: Is this for XLIFF in general or for a particular version?

R: Not necessarily.

Y: If you click on the link it mentions 2.1.

R: But this is the request. It was requested when 2.1 was published. There is no limit for future versions.

Y: It is ok.

R: In the Appendix I mentioned that this is for 2.0 and later.

M: Looking into other examples, they do not mention versions.

R: This was already made by Chet. We cannot change it.

R: I have added the plural module in the XML Schemas Tree. I have also updated the date of the spec and the track changes section to specify that the information the appendix A had been modified.


    Typos in the spec- Lucía

L: I have reviewed the spec and I have found some minor typos on the new module and the spec in general.

M: We have some issues with your sound.

L: I can send an email if that helps.

R: You can create an issue in github so it gets recorded.

L: Sure, I will do that.

 

L: I have noticed, that when declaring that the attributes from the new module in the elements in the core specification, they are done in two different ways: one in the list of attributes, and the other one in the list of attributes within the constraints section. Is this consistent?

M: I see what you mean. We have also this formulation of the attributes from the modules within a constraints section in the following elements definitions: elements/structural/note.xml elements/structural/group.xml elements/structural/xliff.xml elements/structural/file.xml elements/structural/unit.xml

R: we could even delete that information if it is considered noise.

M: Before joining the group, I found it useful. It is informative in my opinion.

R: Instead of putting them as a constraint, we can put it as a note.

M: Yes, that can be moved to a note.

Y: I do not have a specific opinion, but it can be a note.

L: I agree with Mihai, if it is considered useful and informative it can be included in a note.

R: It is not a constraint; it can be a note.

Y: what do mean here as “explicitly allowed”.

R: “explicitly allowed” is not competing with other namespaces.

M: We have the same wording for the declaration of module elements in some cases.

M: The examples where you have “zero or one” in those cases those are really constraints. I think I would just move to a note in the case of attributes.

Y: we do have constraints in those modules?

R: In the new module, we might have to include some statements as constraints. I think that we do not have any constraints when we define modules. There is one in “id”. We might not be doing things consistently. The constraints are helpful when you are writing a tool. They are important. Historically, they were introduced to avoid that tools abuse of the namespace extension mechanism.

R: We can use constraints in limited places. I would just change the attributes constraints into a note and add a general statement. Is that ok?

Y: we might want to have a definition what is a constraint.

R: Another aspect that we might want to clarify is the term “value description”.

 

L: Another topic that I would like to mention is the section “announcements” in the webpage of the TC. The information is quite outdated. We could include some news like: the work done on the new module, the new version (once it will be on public review), the validation tool that was developed by Rodolfo, etc.

 

R: Can you make an issue on github to record this?

L: I will do it. Sure.

 

 

M: I have something that bothers me. When I generate the html, I get a couple of recoverable errors. I can put them in the chat.

Recoverable error at xsl:attribute on line 139 of file:/Users/mnita/third_party/xliff-xliff-22/xliff-22/docbook/xsl/common/l10n.xsl: Cannot write an attribute node when no element start tag is open Recoverable error at xsl:attribute on line 139 of file:/Users/mnita/third_party/xliff-xliff-22/xliff-22/docbook/xsl/common/l10n.xsl: Cannot write an attribute node when no element start tag is open

 

R: there is a reason for that. The tool that converts to HTML or PDF, were created for Oxygen.

M: I ran the merge.

R: I use Oxygen. It was designed by that.

M: I have a fix for that, but it is the stylesheets.

R: We have to use the stylesheets from OASIS.

M: Ok, I see it. I can live with that.

 

 

    Remaining items before XLIFF 2.2 public review?

R: We discussed that we would have to review it internally before the next meeting.

L: Yes, it would be great if that can be done by next meeting, so we can go into the next phase.

 

 

R: No new business, meeting adjourned.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]