In attendance: Yves, Phil, Robert, Chase
As we had only 4 attendees, quorum was not reached. We held an informal discussion of the JLIFF topics that Yves had recently proposed to the list:
Notes
- Whitespace preservation in JSON?
- Robert: JSON always preserves
- C: I agree.
- Yves: region might be to distinguish things like HTML <pre> vs <p> element.
- R: Anything like this is beyond the serialization rules of JSON
- Robert proposes saying we always preserve whitespace, make a note it may change in the future
- Yves: I think it's ok to always preserve whitespace in JSON. The root cause is that we are carrying information about some content being normalizable and processing the extracted data. But we are losing that information to some degree.
- Agreement for now to always preserve whitespace. Document the concern.
- Source/Target language
- Yves thinks the only reason this information is at source/target language is XLIFF is for module support.
- C: That is the outcome I want
- C: We could move this up at least to sub-unit, potentially even further
- Phil: We had been prototyping a service that work on units, having language at the highest level simplified a lot of logic in the service
- Order attribute
- C: Can we do anything less XML-ish than this?
- Yves: Between 1.2 and 2.0 we change the source/target model. 2.0 splits out source/targets individually. This complicates the case.
- C: Let's put a stake in the ground, keep it as a subunit attribute.
- LIOM/JLIFF stuff
- (There is basic agreement with the idea Yves is expressing)
- Namespaces
- C: Is there a way to not declare prefixes at the top of the fragment?
- R: Using _ or $ is fine.
- R: Could there be a wrapper object with a namespace property that namespaces content in that object?
- C: An issue would be mixing in namespaces with the core
- R: Yes, you would have to push the "bubbles" down very low, it would bloat
- R: The separator character might need to be something that's not a valid URI character so that it's easier to split, if we keep the namespace URI inline
- R: We don't want to invent our own namespace binding mechanism
- Y: I really don't think we want to deal with fully-qualified names everywhere.
- R, C: Agree
- Y: JSON-LD has implemented namespaces, but I am nervous about going that way. It is quite a heavy layer.
- P: I have some experience. It may not solve mixed or nested namespaces. It is more of a bubble/encapsulating solution.
- Y: Other solution is prefix. We could also declare them at the top of the document. We could also use reserve a bunch of module prefixes for standard modules. We would need to have a namespace map somewhere. This always provides a way forward for extensions and modules tools don't support, which we haven't discussed.
- R: Should we also allow fully-qualified names? Glossary might be overkill for cases where the namespace is only used once. However I don't like the lack of orthogonality this creates.
- C: We need to evaluate the implementation burdens added for different options, for example working with Jackson (Java) or equivalent declarative JSON mappers
- R: We could use something to indicate prefixes like using numbers or dollar-signs to make it easier to detect
- Metadata module
- C: I will need to fix this, Yves's points are valid
- Y: For nested groups, I thought maybe this would be done like subunits as an array. Detecting the group based on the property may be a problem for some deserializers.
Action Items
- Fix the metadata module - Chase
- Propose updates for handling srcLang/tgtLang/order metadata as described by Yves - Chase
- Review outstanding pull request - Robert [Done]
Next meeting: May 23.