W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > February 2016

XML Core WG Status and Open Actions as of 2016 February 15

From: Paul Grosso <paul@paulgrosso.name>
Date: Mon, 15 Feb 2016 09:04:07 -0600
To: core <public-xml-core-wg@w3.org>
Message-ID: <56C1E8E7.6030900@paulgrosso.name>

The XML Core WG telcons are scheduled for every other week.

Our next telcon was scheduled for 2016 February 17, but
given lack of action and regrets given, we are CANCELLING
this week's telcon.

Our next telcon is scheduled for March 2.


Status and open actions
=======================

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

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 pointed out that Section 4.4 references RFC 3023
which has been superseded by RFC 7303.  The 7303 rules
for determining encoding of XML documents are slightly
different from the 3023 ones.

Henry reviewed the consequences to the spec of changing
3023 to 7303 and sent email with suggested rewording at
https://lists.w3.org/Archives/Public/public-xml-core-wg/2016Feb/0003

ACTION to Norm:  Net editorial tweaking, make this wording
change to the latest XInclude 1.1 draft.  Also, replace
the reference to 3023 with one to 7303.

---

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,
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.
Received on Monday, 15 February 2016 15:11:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 15 February 2016 15:11:57 UTC