RE: [xliff] 101 - FS attributes is Dec-17 draft

[Yves Savourel <ysavourel@enlaso.com>]

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