OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi Bryan, In response to the changes for issue 101. Thanks for removing the module's attributes from the places where it was difficult or next to impossible to implement. The new locations are all fine now in my opinion. -- I disagree with the text: [[ Format Style module does not have a fragment identification prefix. Prefix /fs is reserved in case it became needed in the future developments of this module. ]] Rational: there fragment identification need in this version of the module. If a new version later needs it, its corresponding specification can define the prefix. -- the 'html' text in "... a quick at a glance html preview of XLIFF content using a predefined set of simple html..." should probably be all-capital. -- There is a first one line listing that seems to be unrelated to the Telecaster example. That first line seems to be repeated with more text below the Telecaster example. -- The telecaster listing example in section 5.3.5.1 is missing a the FS namespace declaration. The XSL template could probably gain from some namespace declarations too. -- The smiley face example should probably be moved in the subFs section since it illustrates subFs. -- All examples have non-visible unwrapped text out of the page in PDF. -- The definition of the value for subFs is still muddy (missing a clear explanation of the syntax): we says: [[ The subFs MUST only be used to carry attribute name/value comma-delimited pairs for attributes that are valid for the HTML element identified by the accompanied fs attribute. ]] Maybe: [[ The subFs attribute is used to specify the HTML attributes to use along with the HTML element declared in the fs attribute. It is a list of name/value pairs. Each pair is separated from the next with a backslash (/). The name and the value of a pair are separated with a comma (,). Both literal backslash and comma characters are escaped with a backslash prefix. ]] -- The tables of values for the fs attribute is incorrectly formatted in PDF: it leak at the top of the page. -- The FS attributes are allowed in the <ec> element. I believe the discussion was that it would be allowed only when that element has isolated='yes'. There are no constraint saying so currently. Cheers, -yves

Yves, I agree with all comments you made on the current state of the fs module [especially the missing constraints on <ec>, the rest are minor editorial issues] except one, see inline On Thu, Dec 19, 2013 at 11:55 AM, Yves Savourel < ysavourel@enlaso.com > wrote: -- I disagree with the text: [[ Format Style module does not have a fragment identification prefix. Prefix /fs is reserved in case it became needed in the future developments of this module. ]] Rational: there fragment identification need in this version of the module. If a new version later needs it, its corresponding specification can define the prefix. What exactly will be the prefixes [/fs OR ~fs OR fs= or whatever] obviously depends on the final fragment identification solution we end up having, I do not want to discuss this aspect here. Nevertheless, no one seems to disagree that the module prefixes should have an nmtoken part identical with their standard namespace prefix, in this case fs. I do not see why the fs nmtoken should not be reserved. Even if this module never develops in a way that would require referencing to it, it would be confusing if other modules or extensions took the fs nmtoken and used it for their fragment identification prefix. Thanks and regards dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie

Hi David, all, > Nevertheless, no one seems to disagree that the module prefixes > should have an nmtoken part identical with their standard > namespace prefix, in this case fs. > > I do not see why the fs nmtoken should not be reserved. > Even if this module never develops in a way that would require > referencing to it, it would be confusing if other modules or > extensions took the fs nmtoken and used it for their > fragment identification prefix. -- There is no such thing as a "standard namespace prefix". You cannot enforce a specific prefix for a given namespace or declare that one is the "standard" one. "fs" is just the prefix that happens to be used in the specification for the Format Style module. It's likely that most will use that prefix, but "standard" to me means something very different. -- In this specification the FS module cannot be used with a fragment reference, so there is no point defining a prefix for it. That would be very confusing. -- The argument of using a single prefix for a given module/extension may not hold across versions: You may get two versions of the same module/extension in the same document. Nothing prevents for example to have a new version of the Matches module in the specification 2.1 and have documents that have been annotated by different tools with candidates using one the version 2.0 of the Matches module and the other the version 2.1 of the Matches module. If the modules are backward compatible, there is no issue with that scenario. Cheers, -yves From: Dr. David Filip [ mailto:David.Filip@ul.ie ] Sent: Thursday, December 19, 2013 5:14 AM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] 101 - FS attributes is Dec-17 draft Yves, I agree with all comments you made on the current state of the fs module [especially the missing constraints on <ec>, the rest are minor editorial issues] except one, see inline On Thu, Dec 19, 2013 at 11:55 AM, Yves Savourel <ysavourel@enlaso.com> wrote: -- I disagree with the text: [[ Format Style module does not have a fragment identification prefix. Prefix /fs is reserved in case it became needed in the future developments of this module. ]] Rational: there fragment identification need in this version of the module. If a new version later needs it, its corresponding specification can define the prefix. What exactly will be the prefixes [/fs OR ~fs OR fs= or whatever] obviously depends on the final fragment identification solution we end up having, I do not want to discuss this aspect here. Nevertheless, no one seems to disagree that the module prefixes should have an nmtoken part identical with their standard namespace prefix, in this case fs. I do not see why the fs nmtoken should not be reserved. Even if this module never develops in a way that would require referencing to it, it would be confusing if other modules or extensions took the fs nmtoken and used it for their fragment identification prefix. Thanks and regards dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie

I've updated to add all the editorial improvements we've agreed upon in the resolution of item 101, except the issue around:   ++++++++++++++++++++++++++++++++++++++++++++++++++ -- I disagree with the text: [[ Format Style module does not have a fragment identification prefix. Prefix /fs is reserved in case it became needed in the future developments of this module. ]] Rational: there fragment identification need in this version of the module. If a new version later needs it, its corresponding specification can define the prefix. ++++++++++++++++++++++++++++++++++++++++++++++++++   David, I agree with the rationale given by Yves. I would vote to remove:   ++++++++++++++++++++++++++++++++++++++++++++++++++ 5.3.3 Module Fragment Identification Prefix   Format Style module does not have a fragment identification prefix. Prefix /fs is reserved in case it became needed in the future developments of this module. ++++++++++++++++++++++++++++++++++++++++++++++++++   Once we come to agreement I will implement (or not implement) this change.   Thanks,   Bryan  
Original Message----- From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Thursday, December 19, 2013 10:19 AM To: xliff@lists.oasis-open.org Subject: RE: [xliff] 101 - FS attributes is Dec-17 draft   Hi David, all,   > Nevertheless, no one seems to disagree that the module prefixes should > have an nmtoken part identical with their standard namespace prefix, > in this case fs. >   > I do not see why the fs nmtoken should not be reserved. > Even if this module never develops in a way that would require > referencing to it, it would be confusing if other modules or > extensions took the fs nmtoken and used it for their fragment > identification prefix.   -- There is no such thing as a "standard namespace prefix". You cannot enforce a specific prefix for a given namespace or declare that one is the "standard" one. "fs" is just the prefix that happens to be used in the specification for the Format Style module. It's likely that most will use that prefix, but "standard" to me means something very different.   -- In this specification the FS module cannot be used with a fragment reference, so there is no point defining a prefix for it. That would be very confusing.   -- The argument of using a single prefix for a given module/extension may not hold across versions: You may get two versions of the same module/extension in the same document. Nothing prevents for example to have a new version of the Matches module in the specification 2.1 and have documents that have been annotated by different tools with candidates using one the version 2.0 of the Matches module and the other the version 2.1 of the Matches module. If the modules are backward compatible, there is no issue with that scenario.   Cheers, -yves           From: Dr. David Filip [ mailto:David.Filip@ul.ie ] Sent: Thursday, December 19, 2013 5:14 AM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] 101 - FS attributes is Dec-17 draft   Yves, I agree with all comments you made on the current state of the fs module [especially the missing constraints on <ec>, the rest are minor editorial issues] except one, see inline   On Thu, Dec 19, 2013 at 11:55 AM, Yves Savourel < ysavourel@enlaso.com > wrote: -- I disagree with the text:   [[ Format Style module does not have a fragment identification prefix. Prefix /fs is reserved in case it became needed in the future developments of this module. ]]   Rational: there fragment identification need in this version of the module. If a new version later needs it, its corresponding specification can define the prefix.   What exactly will be the prefixes [/fs OR ~fs OR fs= or whatever] obviously depends on the final fragment identification solution we end up having, I do not want to discuss this aspect here.   Nevertheless, no one seems to disagree that the module prefixes should have an nmtoken part identical with their standard namespace prefix, in this case fs.   I do not see why the fs nmtoken should not be reserved. Even if this module never develops in a way that would require referencing to it, it would be confusing if other modules or extensions took the fs nmtoken and used it for their fragment identification prefix.   Thanks and regards dF         Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie     --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php