Minutes for XML Core WG telcon of 2016 January 20

Attendees
---------
Norm
Henry
Liam
Paul


[4 organizations (6 with proxies) present out of 8]

Regrets
-------
Jirka, proxy to the chair
Mohamed, proxy to the chair

Absent organizations
--------------------
NACS
John Cowan
Innovimax (with regrets, proxy to the chair)
Jirka Kosek (with regrets, proxy to the chair)

Our next telcon is scheduled for February 3.



> 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).
>

Accepted.

>
> 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.

So noted once again.

>
> 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.

Henry pinged various people about helping move XML Schema 1.1 forward
and had no positive responses.


>
> 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.
>

So noted once again.


>
> 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.
>

ACTION to Norm continued.


> ---
> 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.

ACTION to Henry continued.


>
> ---
>
> 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.
>

ACTION to Norm continued.

>
> 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
>
>
>
>