All
Sorry ignore me, it’s been a long day. We have the text-element so everything makes sense.
Phil
Phil Ritchie | Chief Technology Officer | | | Vistatec |
|
| Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. | | | |
| | Think Global | |
|
From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org]
On Behalf Of Phil Ritchie
Sent: 27 June 2017 17:55
To: Robert van Engelen <engelen@genivia.com>; Yves Savourel <ysavourel@enlaso.com>
Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org>
Subject: RE: [xliff-omos] Modules and extensions
In 0.9.4 the text property of the element-xx objects has been removed. It made serialization nice and easy and simplified the model. Was it deemed unnecessary?
Phil Ritchie
|
Chief Technology Officer
|
|
|
Vistatec
|
|
|
Vistatec House, 700 South Circular Road,
Kilmainham, Dublin 8, Ireland.
|
|
|
|
|
|
Think Global
|
|
|
Yves, Chase, Felix, David and other TC members,
I have made the changes to the JLIFF draft schema 0.9.4 and the three examples, as we discussed in the meeting last week. Let me know if this looks OK.
I am working on examples of extensions based on JSON-LD.
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
Like Phil, I’m just wondering about the cost of JSON-LD when various namespaces are mixed in the same object.
Yves Savourel
Localization Solutions Architect | t: 303.951.4523 | f: 303.516.1701 | ENLASO®
previously in this thread people said they are worried about ad hoc created namespace resolution systems. I understand the worry about json-ld complexity, but at least it is a standard solution, with many libraries available. Just my two
cent ...
(I understand that it is likely that people won't go the json-ld path, this is just my last attempt to mention this approach)
Ø 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.
A ‘_’ would be fine with me.
I was just under the impression ‘$’ was the preference for you (and maybe others).
I just wanted to be sure it would work with _javascript_.
Ø Other programming languages may not accept
$ in hard-coded property/variable names…
Quite right. But I wonder if it matters: Languages other than _javascript_ are likely to go through some kind of marshalling of the JSON data into their own data
structures and have ways to address such issue. Actually _javascript_ is probably a special case: the more I work on JLIFF, the more I think it’d be quite hard for most languages to just rely on default automated mapping mechanism to get the proper input/output.
But hopefully I’m wrong.
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).
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
Regarding separator, from quick tests:
Dollar-sign would work, but not period, IMO:
var x = {"name$b": "text"};
var x = {"name.b": "text"};
console.log(x.name.b); à error
More tests are probably needed.
|