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] Feedback on JLIFF examples



Making ‘type’ required creates a nice symmetry. Unless the symmetry is not justified, e.g. when 'ignorable’ is somehow less important or very infrequently used. Perhaps the committee should decide based on use cases, though it is quite a minor decision.

- Robert

On Feb 16, 2017, at 7:30 PM, Chase Tingley <chase@spartansoftwareinc.com> wrote:

Yes, I think we could do what you did with 'segment' in your example -- give it a default value of "segment" in segment case, and make it required in the ignorable case.

(Or if it's clearer to be pedantic, we could always require it.  I think either method should work.)

On Thu, Feb 16, 2017 at 4:23 PM, Robert van Engelen <engelen@genivia.com> wrote:

I think that works well, to use a ‘type’ enumeration. I assume then that ‘type’ will be a required property?

  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 Feb 16, 2017, at 7:14 PM, Chase Tingley <chase@spartansoftwareinc.com> wrote:

Hi Robert,

I think this direction is great -- the use of oneOf is very similar to what I was thinking about to try to clean up the subunit structure a little bit.

Regarding your question about using a boolean called "segment" or a boolean called "ignorable" to indicate type, a third option would be to use an enumerated string:

"oneOf": [
    {
      "properties": {
         "type": { "type": "string", "default": "segment", "enum": [ "segment" ] },
         "canResegment": { "type": "boolean" },
          ...
      },
      {
        "properties": {
          "type": { "type": "string", "enum": ["ignorable"] },
           ....
      }
]

This would mean you can write unit data that looked like:

...
"subunits": [
  {
    "type": "segment",
    "canResegment": false,
    "source": { .... },
    "target": { .... },
  },
  {
    "type": "ignorable",
    "source": { ... },
    "target": { .... }
  }
]

I don't know how if that makes the language bindings easier or harder, but it might make the representation a little clearer.


On Wed, Feb 15, 2017 at 6:14 PM, Robert van Engelen <engelen@genivia.com> wrote:

Phil and Chase,

> I started a discussion on the wiki regarding the example json that are on GitHub. I had a stab at implementing some C# code and came up against an issue. I understand totally that we will come up against things as we progress so please take in the spirit of adventure.

Please see the updated JLIFF wiki page https://github.com/oasis-tcs/xliff-omos-jliff/wiki with some suggestions to incorporate schema constraints to differentiate segment and ignorable.

Cheers,

  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


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







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