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: 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


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