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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-omos message

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


Subject: RE: [xliff-omos] Modules and extensions


Hi all,

 

Looking more into the namespace notation:

We floated the idea that we could use predefined prefixes (like “gls_glossary”) for the modules and full URI (like “myNamespaceURI myprop”) for extensions.

 

But there is one funny twist about the distinction between modules and extensions in XLIFF: Not all tools supports all modules, and for such tools an unsupported module is pretty much like an extension. So how should a tool deal with unsupported modules?

 

For example, the Okapi XLIFF Toolkit does not support the Format Style module, should we output:

 

      "notes": [

        {

          "priority": 9,

          "text": "Note for f1",

          "http://myNamespaceURI attr": "value-in-note",

          "urn:oasis:names:tc:xliff:fs:2.0 fs": "b"

        }

      ],

 

Or

 

      "notes": [

        {

          "priority": 9,

          "text": "Note for f1",

          "http://myNamespaceURI attr": "value-in-note",

          "fs_fs": "b"

        }

      ],

 

The second option would mean each tool would have to somehow know all namespaces for all modules and manage to somehow create an output different from the extensions output. This goes against the “you don’t have to implement all modules” assumption that XLIFF 2 has.

 

Thoughts?

 

Cheers,

-yves

 

 

From: Robert van Engelen [mailto:engelen@genivia.com]
Sent: Tuesday, May 23, 2017 11:11 AM
To: Yves Savourel <ysavourel@enlaso.com>
Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org>
Subject: Re: [xliff-omos] Modules and extensions

 

 

I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.

 

Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is "hard-coded" and so is console.log(x[“name.b”]) also hard-coded, but with a period in the property name that requires quotes).

 

- Robert

 

 

  Dr. Robert van Engelen, CEO/CTO Genivia Inc.
  voice: (850) 270 6179 ext 104
  fax: (850) 270 6179
  mobile: (850) 264 2676
  engelen@genivia.com

 

On May 23, 2017, at 1:03 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

 

Regarding separator, from quick tests:

 

Dollar-sign would work, but not period, IMO:

 

var x = {"name$b": "text"};

console.log(x.name$b); à ok

 

var x = {"name.b": "text"};

console.log(x.name.b); à error

 

More tests are probably needed.

 

cheers,

-yves

 



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