Meeting minutes
https://
https://
Review of Action Items
ACTION: Issue #26 - Steven thinks is done.
All ACTIONs done; some waiting on Steven to merge
ACTION: Steven to merge changes from action this week
Implementations MAY report errors (even though errors represent MUST requirements)
Status of Implmentations
JWL: javascript implmentation is mature enough to run tests - and runs them all without crashing! 6/200 tests failing in about 3.4s to run them all
All: Well done!
JWL: 300 ms to do iXML 'dog food' test
(transformation of iXML into XML)
JWL: I hadn't quite understood the precedence of marks in the spec
JWL: also really strikes me how whitespace profligate it has become
JWL: makes retention of comment position very tricky
JWL: All tests assume new lines (etc) assume unix: problems for me on windows
ACTION: JWL to raise issues for windows whitespace issues
ACTION: JWL to raise issues illustrating problems with comments in xml representation (e.g. comments on either side of repetition operator)
SP: delivering tutorial to Prague
SP: my implementation currently down due to ISP issues: will be up again soon.
Review and resolutions of issues
#25 and #26 are closed, only leaves #66
NDW: I made an effort to summarize as 3 choices. I think we have to pick one.
SP: I don't want to be against namespaces in the output, but have strong feelings about how they are specified. I want them to be less specific to a single output format.
SP: If we are to do this, I want it to be more about how we control the input and output generally, not just namespaces in XML
SP: I also need to understand the objections to my namespaces proposal
NDW: @ mark identifies attributes. xmlns as an attribute name is forbidden.
SP: a parser has to recognise it as not an attribute: that notation was chosen for backwards compatibility. But it still looks like an attribute. Serialised as text, it is identical.
JWL: there are two scenarios: 1/ where we run iXML and get out serialised XML that is processed later. 2/ (more frequently) the iXML output is not serialised, but uses a build tree model which is used for further processing. Under that circumstance, it is not an attribute.
NDW: it also puts enormous pressure on the grammar author: namespace declarations are now local, and open up the grammar author to a number of issues.
SP: What stops my system from working now?
TFJH: at the moment, the spec does not proscribe xmlns: attributes being processed differently from XML attributes, and would result in badly formed XML
JWL: At the moment namespace definitions under SP's proposal would allow namespaces to be bound to arbitrary URLs
NDW: there are a number of cans of worms that are enabled by this behaviour, and I can see no reasons to do so.
TFJH: I want to return to producing non-XML outputs. My concern is that the grammar is providing necessary information to make implicit information in the input into explicit information in the output (XML); furthermore I am concerned that the information necessary in the grammar depends on the output format.
BTW: It is my understanding that the Spec explicitly talks about XML output: a generalised output may be laudable, but it would require major re-writes to the spec
SP: But iXML isn't specific to XML, it's about an interchange format
TFJH: Although I think how you envisage iXML is of course important, what iXML IS is defined in the spec, and that is explicitly XML.
TFJH: May I suggest that we table non-XML outputs for V.Future
(General agreement)
Returning to namespaces, options (from Norm's email) are 1) simple namespaces 2) Namespaces as attributes (implementations to handle as namespace declarations) 3) status quo
ACTION: Option 3
NDW: I will be making a proposal to forbid xmlns at the start of attribute names.
TFJH: what Norm is asking for is already the case, IMO (well formedness constraint)
NDW: That's true, and is enough for me for today.