W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > March 2005

Agenda for XML Core WG telcon of 2005 March 30

From: Paul Grosso <pgrosso@arbortext.com>
Date: Mon, 28 Mar 2005 10:15:52 -0500
Message-ID: <F13E1BF26B19BA40AF3C0DE7D4DA0C0303C7C8CF@ati-mail01.arbortext.local>
To: <public-xml-core-wg@w3.org>

We have an XML Core WG phone call scheduled for Wednesday, 
March 30, from
          08:00-09:00 Pacific time aka
          11:00-12:00 Eastern time aka
          16:00-17:00 UTC
          17:00-18:00 in Ireland and the UK
          18:00-19:00 in middle (most of) Europe
on the Zakim W3C Bridge, +1 617 761 6200, passcode 9652#.
We also use IRC channel #xmlcore on irc.w3.org:6665 .

*** For this telcon only, the local time in the UK and
Europe is one hour later than usual due to the fact that
North America starts daylight time this weekend instead
of last weekend.  We will be back to regular local times
for all WG participants next week. ***

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.

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.

The new XML Core WG charter should be in the process
of getting approved.  We can expect a new call for 
participation soon by the end of this week.

The WG needs to review the Binary XML documents:

Norm is reviewing them already for the TAG.

Dmitry, who is on the XBC WG, is also familiar with 
the documents.

ACTION to Dmitry:  Send email before the telcon to 
the XML Core WG outlining any issues in these documents 
that may be of interest to the XML Core WG.

He recommends waiting until this Thursday to review
the measurement documents which will be changing
(the other two are ready for review).  There will
be a fourth document, Characterization, that will
be published on or soon after this Thursday.

ACTION to Lew:  Review the documents and report to
the WG by the end of March.

Richard has been volunteered to review the 
XPath 2.0/XQuery 1.0 Data Model document, to be published 
as a LC WD in late March or early April (though there are 
no plans to make any changes to it at this time, so the
review can start at any time).

ACTION to Richard:  Review the XPath 2.0/XQuery 1.0 Data 
Model document:  

Norm says the two key areas for XML Core to review are
Constructing a datamodel from an infoset and constructing 
an infoset from the datamodel.

Richard remembers there being something strange about 
the PSVI, and he wants to check on that too.

We should review the Compound Document Format (CDF) 
Use Cases and Requirements document:
which talks about "combining separate component technologies 
(e.g. XML-based languages, elements and attributes from 
separate namespaces)...[including]... compounding by 
reference and by inclusion."

JohnC did a pass and saw nothing for XML Core WG.

Paul still hopes to look at it.

3.  XLink update.

Our WG Note "Extending XLink 1.0" has been published:

A charter modification has gone to the AC:

While we aren't quite chartered for this yet, we did
discuss it some at our f2f:

4. XML errata.  The published 1.0 errata document is [8], the
   published 1.1 errata document is [9], and the NEW PUBLIC
   Potential Errata (PE) document is [7]. 

See the discussion of IRIs and the "MAY" paragraph
under item 5. Namespaces in XML below (which actually
occurred during our f2f under the XLink discussion).

We need to make some IRI related errata to XML 1.0 
and 1.1 (for system ids). 

Note this does NOT mean that we would change the 
reference to 2396 to now be 3986 because that could
imply other changes.

ACTION to Richard:  Draft wording for the erratum 
to XML 1.0 and 1.1 updating the IRI wording (and
referencing the MAY paragraph).

We had a question about the XML Test Suite arise; see

5. Namespaces in XML.

Richard suggested we take NS 1.1 and revert the two 
substantive changes (IRI and undeclared namespaces) 
to create NS 1.0 2nd Ed. The WG has consensus to do 
that, and we got approval from the team to do so.

Ongoing ACTION to Richard:  Produce a draft for NS1.0 2nd Ed.

We note that the IRI spec is now finished-RFC 3987-so 
we have to issue an erratum for NS 1.1 for this.  We
discussed some details of this under the XLink discussion:
Briefly, 3987 does have some wording (the "MAY" paragraph) 
about what used to be called unwise characters.  For the 
NS 1.1 erratum, the MAY paragraph doesn't apply since 
namespace names cannot have the unwise characters.  (The 
MAY paragraph will be needed for XML 1.* system identifiers.)

ACTION to Richard:  Process an erratum to NS 1.1 to
refer to RFC 3987: http://www.ietf.org/rfc/rfc3987.txt

6. Xinclude Rec was published 2004 December 30 at:

Our XInclude potential errata document is at:

for the latest status of the open PEs.

PEX1 Fatal XInclude errors in unactivated fallbacks
We will add a paragraph to "Section 4.4 Fallback Behavior" 
about how there are no fatal errors relating to fallback-both 
errors within fallback elements and errors due to the wrong 
number of fallback elements-unless there is a resource error 
with the xinclude element surround this(these) fallback 
element(s). We will also add something after the third 
sentence of section 3.2 to this effect.

ACTION to ???:  Suggest actual wording.

PEX2 URI or IRI errors handling
There will be no change to the spec.

We don't expect implementors of XInclude to implement 
IRI processing, so whatever ends up happening with 
respect to IRIs isn't really the fault of the XInclude 
processor. However, we don't want to license such behavior, 
so we don't want to change our current wording here. 

ACTION to ???:  Reply to the commentor.

PEX3 What is an error (subcase on accept attribute value)
Can we close this as being a duplicate of PEX7?

PEX5 XML encoding detection in parse="text"

PEX6 parse="text" and Byte-Order Mark
What are the *{LE,BE} encodings?

PEX14 What if encoding is not an EncName?
While Paul thought this was a duplicate of PEX7,
Francois pointed out we could distinguish between
the PEX7 case and the case where the encoding
attribute value isn't even lexically valid per
XML 1.0 production [81]:

[81]  EncName ::= [A-Za-z] ([A-Za-z0-9._] | '-')* 
    /* Encoding name contains only Latin characters */

PEX15 XPointers with percent escapes: what type of error?

7. xml:id.

The CR was published (2005 Feb 8) at

The (public) xml:id LC issues is at:
The LC DoC is at:
Our implementation report is at
We have a test suite cover page at

Norm sent some email at
and a sample of his implementation feedback at

ACTION to Norm:  Add a link to the test suite from
your implementation feedback report.

ACTION to DV, Richard:  Run your implementation on the 
test suite and produce some feedback report.

ACTION to Norm:  Ask ERH to run his implementation on 
the test suite and produce some feedback report.

8.  Associating stylesheets--awaiting TAG action.

9.  absolutivity of [base URI]
    Norm has asked a question about the absolutivity of [base URI]:

We discussed this at our f2f:

We have CONSENSUS that base URIs are always absolute. 

The last sentence of the first 
paragraph of section 5.1 of RFC 3986 says "If the base 
URI is obtained from a URI reference, then that reference 
must be converted to absolute form and stripped of any 
fragment component prior to its use as a base URI."

Since the infoset and xml:base refer to 2396, it's not 
clear whether the fragment identifier is part of the 
infoset's [base URI] or not as life stands today. 

Richard: In 2396, base URIs can have fragment identifiers,
but this doesn't matter because they aren't used when doing
absolutization or determining if there is a same document ref.

In 3986, base URIs don't have fragment ids, and again this 
doesn't matter for resolution, but it is essential that it
be stripped off for the determine of whether something is a
same document reference.

In the infoset, we do expose the base URI as a property, and 
if we were to switch xml:base and XML itself from 2396 to 
3986, the value of the base URI property would be different.
Richard isn't sure we want to do that.

ACTION to Richard:  Draft a message for Roy et al. and send
to the XML Core WG for discussion (later, to be sent to
the uri group and the tag).


[1] http://www.w3.org/XML/Group/Core
[2] http://www.w3.org/XML/Group/Core#tasks
[3] http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0027
[8] http://www.w3.org/XML/xml-V10-3e-errata
[9] http://www.w3.org/XML/xml-V11-1e-errata
Received on Monday, 28 March 2005 15:17:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:34 UTC