Agenda for XML Core WG telcon of 2016 January 20

We have an XML Core WG phone call scheduled for Wednesday,
January 20, from
08:30-09:00 Pacific time aka
11:30-12:00 Eastern time aka
16:30-17:00 UTC
16:30-17:00 in Ireland and the UK
17:30-18:00 in middle (most of) Europe

We are now using Webex for our conferences. See
https://www.w3.org/XML/Group/Core#std-telcon-info

You can join by phone by dialing +1-617-324-0000 directly and
using an access code of 643 434 633#.

You can also use the Webex client (and have it call you)
by pointing your browser at
https://mit.webex.com/mit/j.php?MTID=mc1156896bec942d319521903648bd6c4.

We also use IRC channel #xmlcore on irc.w3.org:6665 .

See the XML Core group page [1] for pointers to current documents
and other information. If you have additions to the agenda, please
email them to the WG list before the start of the telcon.

Please also review our group page's task list [2] for accuracy and
completeness and be prepared to amend if necessary and accept it
at the beginning of the call.


Agenda
======
1. Accepting the minutes from the last telcon [3] and
   the current task status [2] (have any questions, comments,
   or corrections ready by the beginning of the call).


2. Miscellaneous administrivia and document reviews.

If, for any of the subitems to this agenda item, there has
been no progress on it by February 3, that item will be
removed from our running agenda.

See https://www.w3.org/XML/Group/Core#xml-pe-issues
for XML potential errata.

See https://www.w3.org/XML/Group/Core#xmlns-pe-issues
for XML Namespaces potential errata.

XML Potential Errata
--------------------
Comment that “or by the Byte Order Mark” is lacking in section 4.3.3:
http://lists.w3.org/Archives/Public/xml-editor/2013OctDec/0002

Comment that an entity cannot “begin” with a BOM as suggested in section 
4.3.3:
http://lists.w3.org/Archives/Public/xml-editor/2013OctDec/0003

ACTION to John and Henry: Review and comment on the above two comments
on the discussion of BOMs in section 4.3.3 of the XML spec.

----

Comment about documents with an "empty DTD":
http://lists.w3.org/Archives/Public/public-xml-core-wg/2014Jan/thread#msg8
and
http://lists.w3.org/Archives/Public/xml-editor/2014JanMar/

Henry suggests we could probably make the XML spec clearer here;
see also his comments at
http://lists.w3.org/Archives/Public/xml-editor/2014JanMar/0004

Paul sent the WG response at
http://lists.w3.org/Archives/Public/xml-editor/2014JanMar/0005
and there was more back from the commentor at
http://lists.w3.org/Archives/Public/xml-editor/2014JanMar/

Henry referenced Paul's email at
http://lists.w3.org/Archives/Public/xml-editor/2014JanMar/0010
especially Paul's suggestion in point 4, though Henry wasn't
sure he agreed with the suggestion.

ACTION to Henry:  Post some suggestion(s) to the list about
how to address: Comment about documents with an "empty DTD".

----

Question about normalization checking in XML 1.1
------------------------------------------------
John Cowan forwarded an email for us to consider at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2014Dec/0026
which I've also forwarded to the xml-editor list at
http://lists.w3.org/Archives/Public/xml-editor/2014OctDec/0000
for official/archive purposes.

Paul wrote some comments in email at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2014Dec/0028

Henry checked with Richard who agrees it's a bug, though how
to fix it isn't obvious. Probably the only candidates for not
being normalized are (internal and external) doctypes per email at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2015Jan/0004

ACTION to Norm and Henry: Review the email about normalization checking
in XML 1.1 and suggest an appropriate corrigendum.

----

Potential Erratum to Namespaces
-------------------------------
CMSMcQ raised a potential erratum against Namespaces at
http://lists.w3.org/Archives/Public/xml-names-editor/2014Sep/0000
with WG discussion started at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2014Sep/0019

He says that our latest wording in the definition of 'namespace name'
(section 2.1) appears to say that an element with no namespace binding
in scope is in no namespace as opposed to saying its namespace is
unknown (thereby leaving the possibility that its namespace
information may be determined by some other methods).

Norm, Paul, and Henry posted some thoughts on this, and none
of us feel that the current wording is necessarily bad enough
to be worth any change. In particular, Norm doesn't agree with
what Michael thinks should be the case. Henry points out that
HTML5 does "make use of" defining namespaces without the
namespace spec mechanism.

Henry had some more (private) exchanges with Michael, and
Henry will summarize the discussion for the WG.

ACTION to Henry: Summarize and provide current status of
the discussion of this namespace potential erratum.


3. Submitting XML Schema 1.1 to ISO

See also
https://www.w3.org/XML/Group/Core#xml-schema

We have decided we will first publish XML Schema 1.1 2E (with
approved errata). After that, we would send XML Schema 1.1 2E
(only) to ISO.

Loren has offered to do the editorial duties, and David
talked to CMSMCQ about getting some more help in the details.

It looks like there are 3 bugs for Structures, none for Datatypes,
but after checking with Michael, he found
https://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.errata-2012.html
which shows 8 errata items whereas bugzilla shows only 3.

We discussed
https://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.errata-2012.html

Henry figures we can just publish this document.

Loren believes the latest document includes everything,
so the next step is to push it through the tool chain.

We will need a diff (or list of changes).
Loren says the diff is already available.

We needed to consider whether any of the changes are normative
and/or require a change to the test suite.  After some discussion,
we decided we should just create a PER.

We still need to:  Create the PER, i.e., XML Schema 1.1 Second Edition,
and post (e.g., at http://www.w3.org/XML/Group/2014/12/xschema11.html)
for the WG to review.

ACTION to David: Consider how to further progress on this work item.

If by the February 3 telcon we have no more idea how to make
progress on this, I plan to delete this item from our running agenda.


4.  XInclude 1.1--see http://www.w3.org/XML/Group/Core#xinclude

On 2015 June 30, we published our second XInclude 1.1 CR at
http://www.w3.org/TR/2015/CR-xinclude-11-20150630/

This CR period ran minimally through the end of August; at this
time we appear to have enough implementations (though Henry may
supply another), and we are waiting to update the spec, test suite,
and implementation report to go the PR.

Norm has an implementation in XML Calabash.
He has also implemented XInclude 1.1 in MarkLogic.

Jirka reports that there is another XInclude 1.1 implementation
in XML Mind XML Editor.  See:
http://www.xmlmind.com/xmleditor/changes.html#v6.2.0

Note also the desire for another test case for the XInclude test suite per
http://lists.w3.org/Archives/Public/public-xml-core-wg/2014Apr/0000

ACTION to Norm:  Update the implementation report and test suite.

---

Henry had started working on extending Richard's XInclude 1.0
implementation to do XInclude 1.1.  Henry said he had made some
progress, but it looks like more work than he has time at present,
so we shouldn't wait for such.

---

Henry points out that Section 4.4 [11] references RFC 3023
which has been superseded by RFC 7303 [12].  The 7303 rules
for determining encoding of XML documents are slightly
different from the 3023 ones, and might even be a bit easier to
implement.  He doesn't think you can get away from starting to
read at least some documents twice, but he'd like to discuss
this on our next call.
[11] http://www.w3.org/TR/xinclude-11/#text-included-items
[12] https://tools.ietf.org/html/rfc7303

ACTION to Henry:  Review the consequences to the spec of
changing 3023 to 7303 and report to Norm so that he can
adjust the spec accordingly.

---

Paul raised the question of whether the spec requires
the support for RFC 5147. It isn't mentioned under
Application Conformance, but the description of fragid,
it says "for text processing, [the fragid value] is
interpreted as a [IETF RFC 5147] fragment identifier"
and it doesn't discuss what to do if an implementation
doesn't support that.

Norm suggests that we can't force implementations to
support it and that we should clarify the spec to say
that lack of support for fragid when parse=text
should be a recoverable error.

Henry and Paul agree with that suggestion.

ACTION to Norm:  Update the spec to clarify that lack
of support for fragid when parse=text should be a
recoverable error.


paul

[1] http://www.w3.org/XML/Group/Core
[2] http://www.w3.org/XML/Group/Core#tasks
[3] https://lists.w3.org/Archives/Public/public-xml-core-wg/2016Jan/0007

Received on Monday, 18 January 2016 16:20:09 UTC