chat log - ODF 13 Feb. 2017

[Patrick Durusau <patrick@durusau.net>]

Greetings!

Our chat log for today:

anonymous morphed into Jos van den Oever
Jos van den Oever: I'm travelling so my phone and internet connection
will waver somewhat.
anonymous morphed into Thorsten
Andras Timar 2: Hi all!
Jos van den Oever: i've an update on the faster loading of spreadsheets
Jos van den Oever: forget what issue # that was
Patrick: 7 of 9
Patrick: https://issues.oasis-open.org/browse/OFFICE-2102
Regina Henschel: Jos: Likely
https://issues.oasis-open.org/browse/OFFICE-2087
Andreas J Guelzow1: Hi, I have just joined the call although I don't
seem to hear anything...
Patrick: 8 of 9 - hello Andreas
Jos van den Oever: sorry for mentioning text:a that obviously requires
collapsing in all descriptions
Jos van den Oever: All the elements you list as not supporting <text:s>
seem to be fields which do not have long stretches of text
Jos van den Oever: only hidden-paragraph would
Jos van den Oever: ODF collapse rules are not like XML collapse rules
Michael Stahl: Jos: text:text-input and text:variable-input and
text:script are the elements where this probably matters a lot
Jos van den Oever: Yes, in those elements it seems not unreasonable to
not collapse
Jos van den Oever: certainly text:script should not collapse and should
not have <text:t>
Jos van den Oever: i mean <text:s>
Michael Stahl: Jos: i agree on text:script
Jos van den Oever: so given that there is one tag that should not do ws
collapse at all, there might be more
Patrick: regina - which elements generate content and which take content
from the file
Jos van den Oever: the *-input fields do not calculate their contents,
but most of the others do
Jos van den Oever: it would indeed be good to have that annotated in a
computer-readable way
Jos van den Oever: An interesting aspect of the ODF ws collapsing is the
handling of edges of elements
Patrick: collapse on <text:keywords> problematic b/c format is
implementation-dependent
Patrick: possibly a problem for <text:printed-by>
Jos van den Oever: The collapse algorithm deals with a collapse at the
end of a field. E.g. <span><u>abc </u> def</span> would have one space
between c and d and it would be underlined.
Jos van den Oever: if <u/> was  calculated value, should we still
collapse those two space?
Jos van den Oever: i see no scenario where that would be useful or expected.
Jos van den Oever: we could clarify 'permits the inclusion of character
data' to mean that the field should not hold editable data, if it is
calculated it it is not editable
Jos van den Oever: that still leave text-input as ambiguous, one could
clarify further 'editable as paragraph text'
Jos van den Oever: which one could argue excludes text-input and
variable-set and script.
Jos van den Oever: then we've more or less united the texts of 1.1 and 1.2
Jos van den Oever: apart from at least ruby and hidden-paragraph which
need more explanation
Jos van den Oever: (sorry for just typing, i'm in a noisy train)
Jos van den Oever: i can hear you all fine though
Michael Stahl: i don't like 'editable as paragraph text' - that is an
implementation detail - e.g. for text:input, Word and LO 5.2 allow
editing as paragraph text, but OOo 3.0 did not
Michael Stahl: ^ meant text:text-input
Michael Stahl: what does the hidden-paragraph field's content actually do?
Jos van den Oever: it's there, just like a <span> i guess, it's not
specified
Jos van den Oever: from the functionality, it's not useful to have
character content in there except as a handle to access the
functionality e.g. to change the conditional
Patrick: It controls the display of the text:p where it is embedded.
oddly, it allows character data content but the condition for
display/hiding is an attribute
Patrick: and you can have more than one in a single text:p
Michael Stahl: but the condition attribute should be sufficient for
that? why does it need character content?
Jos van den Oever: Michael: perhaps as a handle so you can access the
functionality via the ui, it's a paragraph level functionality, so it's
weird
Michael Stahl: i can't find a way to enter character content into a
hidden-paragraph field in LO 5.2
Michael Stahl: if i edit the xml and put something there it isn't
imported (the field is imported but contained content ignored)
Jos van den Oever: allowing character content in there might be an error
originating in the fact that there is 'paragraph' in the element tag
Jos van den Oever: then let's mark it as an error in 1.2 and say that no
character content is allowed in there, i.e. it should not be processed,
but it's presence should not halt processing
Michael Stahl: Jos: i wouldn't object to that
Jos van den Oever: it would make the current ws discussion easier
Patrick: The annotation - the gray material in the text, was
auto-generated from the schema by scripts - so need to check the schema
for an error on that point.
Patrick: take up with more research next week!

Hope everyone is at the start of a great week!

Patrick





-- 
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau

Attachment: signature.asc
Description: OpenPGP digital signature