Meeting minutes
iXML meeting
Review of action items
ACTION: 2023-01-10-b continues
ACTION: 2023-01-10-d continues
ACTION: 2023-01-10-f continues
ACTION: 2023-01-10-h continues
ACTION: 2023-02-07-a continues; Steven had trouble logging in
ACTION: 2023-02-07-b continues; merge with 2023-01-10-d
ACTION: 2023-04-11-a continues
ACTION: 2023-04-11-b continues
ACTION: 2023-04-11-c continues
ACTION: 2023-04-11-d completed https://
Status reports
John: I've added the ability to switch off indentation becuase it interferes with test results
John: The problem isn't the test suite, it's the XML tree to display. The spec uses the term "elide" but doesn't clearly define it. Are you permitted to completely remove whitespace?
Steven: Yes, one of my examples at the web conference has two spaces but they disappear.
John: Right, the serializer uses indentation in the indentation method and my reading is that under those circumstances, it's possible for purely whitespace nodes to be removed.
John: The processor certainly produces two spaces.
Bethan: I'd understand "elide" to mean leave out.
John: I think of it as to shorten.
Some discussion of the use of "..." in elided text.
Norm: I published an update that fixed some bugs.
Steven: I haven't made any changes in the last month as I recall.
Some discussion of the web conference.
Steven: At the last moment, they moved the tutorial but they didn't tell anyone.
Much enthusiasm from a small tutorial audience.
Steven: I also gave a talk on the dev day and that had about 20-25 people.
Publication plans
No discussion this month.
Issues #174 and #175 BOM
Steven: I think we agree to ignore the BOM at the beginning but not to ignore them in the middle (in the case of concatentated files)
Micheal: I'm puzzled by one thing. I think of operations like recognizing the BOM, setting the endianness, etc. as something that gets handled by a low-level system routine.
… that provides the program with a sequence of characters.
… If you're iXML processor is seeing a BOM, you have an OS issue. Am I just spoiled?
Steven: I do agree, especially since UTF-8 doesn't need a BOM.
Norm: If you open a UTF-8 file with a BOM in Java, the first two bytes you read are a BOM!
Michael: Can we somehow find a way to say ignore a BOM and also say in passing that you shouldn't be seeing one?
Norm: We could, but it isn't going to change anything.
Michael: Okay, but I would find it useful as a reader. I don't think we should take the position that that's normal.
… I think we should say it about the input string as well.
… Otherwise, you have to tell users to write their grammars to ignore the BOM.
General agreement.
Michael: I think that should be a "should" not a "must".
Some discussion of BOMs in UTF-16.
Norm asserts that in UTF-16 files, the BOM is stripped off by the OS/library.
Michael: I think it's sufficient to say "if it's UTF-8" and leave it to implementations to document that.
ACTION: 2023-05-09-a: Norm to revise the erratum to include stripping the BOM from UTF-8 input strings (as a should)
Issue #176 Encoding CR, NEL, LINE SEPARATOR etc
Norm: I don't think there's a bug here.
Some discussion of the significance of "If you use the XSLT and XQuery Serialization..."
Michael: Can we have a non-binding note somewhere that observes how XSLT and XQuery Serialization works.
Norm: I think we just need a note.
Michael: It will arise for some people, I'm persuaded we should add a note describing it.
Steven: I'm not sure how this effects interoperability. We talk about serialization. To what extent should we more normative than we are?
John: We stop at the point where you've produced an XML tree as a serialization, how you get that into text isn't part of our text.
Norm: I'd be in favor of a normative reference to XSLT/XQuery serialization.
Michael: I'm not sure our requirements are the same. We don't need to be about "round trip" data model instances.
… I wouldn't be at all unhappy if an iXML processor serialized those CRs as literal characters and not character references because they only reason they're there is that the OS convention for line beaks.
… When they get written out, I want the same convention and encoding them as #d; and just using line feeds isn't just surprising, I don't like it very much.
… This is an example of a case where serialization is attempting to deal with problems that aren't ours.
Steven: There's the related question of what should happen if you output a newline in an attribute.
Some discussion of how the email was rendered.
https://
(It appears that the something went wrong with Steven's mailer's interpretation of 
 in the message Norm sent)
Michael: I'm nervous about a normative reference to XSLT and XQuery Serialization because it's a big spec.
… I think an informative reference would be a good idea.
Norm: Would you be ok with a literal newline in the attribute value?
Michael: I've been asking myself that question...I'm going to give you two answers: yes and no.
… As a spec lawyer, that would trouble me somewhat, but as a markup practitioner, I decided years ago that if you care about details like that, use markup to retain it. Literal whitespace gets rearranged by lots of tools.
Norm: Proposal: an informative reference to the XSLT and XQuery Serialization specification and a short discussion somewhere in the specification about the consequences of serialization (attribute values with whitespace, etc.)
John: You also have to be aware of indentation changing the output.
Michael: Our specification doesn't overtly contemplate indentation.
Michael: I think Norm's suggestion is a good one. We have a section on serialization...
Steven: We also have a "hints to the implementor" section that might be a better place.
Michael: I think an informative reference and prose in either or both of those sections would be a good idea.
ACTION: 2023-05-09-b: Norm to make a pass attempting to describe serialization
ACTION: 2023-05-09-c: Steven to produce new sample grammars for issue #139 for discussion in June.
Steven: Let's make sure JSON is on the agenda for next month.
Steven: Do we have a renaming proposal?
John: No, not yet.
ACTION: 2023-05-09-d: Steven to produce a discussion document for renaming (issue #13)
Reminder: everyone should read John's message about dynamic renaming
Next meeting is 13 June 2023.
Adjourned.
rrsange, publish minutes