Minutes for XML Core WG telcon of 2005 March 23

Attendees
---------
 Paul 
 Glenn
 Arnaud 
 Dmitry
 Norm 
 Philippe xx:07
 Daniel  
 François 
 Lew  xx:24
 John  xx:08

[9 organizations (9 with proxies) present out of 11]

Regrets
------- 
Richard
Henry

Absent organizations
--------------------
NIST 
University of Edinburgh (with regrets)

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

Note:  Next week's telcon (2005 March 30) will be held 
11:00-12:00 Boston time which will be an hour later than 
usual local time for the UK and Europe since North America 
shifts to daylight time the first Sunday in April instead 
of the last Sunday in March.

Philippe reports that it looks like the new XML Core charter
will be approved within the week.  This means we will have
a new call for participation soon--expected at the end of
next week.

> The WG needs to review the Binary XML documents:
> http://www.w3.org/TR/2005/WD-xbc-measurement-20050224/
> http://www.w3.org/TR/2005/WD-xbc-properties-20050224/
> http://www.w3.org/TR/2005/WD-xbc-use-cases-20050224/ 
> 
> 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 our next 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.

ACTION to Lew continued.

> 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:  
> http://www.w3.org/TR/2005/WD-xpath-datamodel-20050211/
> 
> 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:
> http://www.w3.org/2004/CDF/Group/specs/CDR/usecases/1.0/cdr-use-cases-reqs.xml
> 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."
> 
> We are still looking for volunteers to review this document.

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

> 
> 3.  XLink update.
> 
> Our WG Note "Extending XLink 1.0" has been published:
> http://www.w3.org/TR/2005/NOTE-xlink10-ext-20050127/
> 
> A charter modification has gone to the AC:
> http://lists.w3.org/Archives/Member/w3c-ac-members/2005JanMar/0036
> 
> While we aren't quite chartered for this yet, we did
> discuss it some at our f2f:
> http://www.w3.org/XML/2005/02/xml-f2f-20050303-minutes.htm#xlink
> 
> 
> 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).

ACTION to Richard continued.

> 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:
> http://www.w3.org/XML/2005/02/xml-f2f-20050303-minutes.htm#xlink
> 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

ACTION to Richard continued.

> 
> 6. Xinclude Rec was published 2004 December 30 at:
>    http://www.w3.org/TR/2004/REC-xinclude-20041220/
> 
> It has been brought to my attention that we apparently failed
> to look at the public XInclude comments list for comments
> received during the PR review which is basically the October
> archives for this list:
> http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2004Oct/
> We will treat these are errata.  
> 
> DV volunteers to be editor of the XInclude errata process.
> 
> Our XInclude potential errata document is at:
> http://www.w3.org/XML/2005/01/proposed-xinclude-errata
> 
> ACTION to DV:  Make corrections, additions as outlined
> in Paul's email at:
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Feb/0064
> 
> We discussed XInclude errata at our f2f; see
> http://www.w3.org/XML/2005/02/xml-f2f-20050303-minutes.htm#xinclude
> for the details.
> 
> In response, JohnC noted:
> 
>  In PEX6: whether or not an initial U+FFEF is part of a 
>  text/plain document (or in our case, a document which is 
>  being treated as text/plain) depends on the character encoding.  
>  If it's UTF-{8,16,32}, then no, it's a BOM and should be 
>  discarded.  If it's UTF-{16,32}{LE,BE}, then yes, it's a
>  ZWNBSP character and should be kept.
> 
> François replies:
> 
>  FWIW, I agree with John that here the initial U+FEFF should be 
>  considered a BOM and discarded, but I find some confusion in 
> the above. 
>   In the case presented in PEX6, it has been determined (through 
>  defaulting) that the encoding is UTF-8, so all the rest about 
>  UTF-{16,32} and UTF-{16,32}{LE,BE} is non sequitur.
> 
> Richard thinks we should probably have a clarification
> for any encoding:  when the first character is interpreted
> as a BOM it should be discarded.  It is interperted as a 
> BOM in UTF-{8,16,32} but not in the *{LE,BE} encodings.
> 
> DECISION to add clarification per the above paragraph.
> 
> ACTION to DV:  Update the xinclude PE document with
> our latest decisions.  Add the comments from the
> October and November archives.

Done.

Paul also sent email outlining open issues at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0022

PEX2 URI or IRI errors handling
-------------------------------
At our f2f, we said:

 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.
 [Paul doesn't really understand how to explain
 this, so someone else will have to write the
 proposed response here.]

Someone needs to draft the proposed response.

Still open.

PEX3 What is an error
---------------------
At our f2f, we said (among other things):

 As far as the case with accept="foo" (mentioned
 in the comment), the definition of the accept
 attribute in section 3.1 does not make this an
 XInclude error of any kind, though it may cause
 an error in a lower level that might result in a
 resource error, for example. Those present didn't
 seem quite satisfied with this resolution, so after
 some discussion, we decided to revisit this later.

Still open.

PEX5 XML encoding detection in parse="text"
-------------------------------------------
See the PE document.

Still open.

PEX11 Reference to RFC 2279 should be RFC 3629
----------------------------------------------
This is the RFC for UTF-8. We note that 2279 is 
listed in the normative references but there is 
actually no reference to it in the document. 

We will ask François for his opinion of how to 
handle this. Note that 3629 has a section about 
the BOM.

DECISION: Francois believes we should update the 
reference from 2279 to 3629.


PEX14 What if encoding is not an EncName?
-------------------------------------------
http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2004Oct/0000
ERH asks "what should I do if the encoding attribute 
does not satisfy [XML 1.0's EncName] production [81]
<http://www.w3.org/TR/REC-xml/#NT-EncName>?

Still open.


PEX15 XPointers with percent escapes: what type of error?
-----------------------------------------------------------
http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2004Oct/0008
ERH says:

 Since the xpointer attribute is not a URI reference,
 %-escaping must not appear in the XPointer.... [He
 suggests clarifying that such would be] a resource
 error rather than a fatal error.

Still open.


> 
> 7. xml:id.
> 
> The CR was published (2005 Feb 8) at
> http://www.w3.org/TR/2005/CR-xml-id-20050208/
> 
> The (public) xml:id LC issues is at:
> http://www.w3.org/XML/2004/xml-id/lc-status/status-report.html
> The LC DoC is at:
> http://www.w3.org/XML/2005/01/xml-id-lc-doc.html
> Our implementation report is at
> http://www.w3.org/XML/2005/01/xml-id-implementation.html
> We have a test suite cover page at
> http://www.w3.org/XML/Test/xml-id/
> 
> The issue of xml:id vrs C14N and the definition of
> namespaces is ongoing, originally in the xml:id 
> comments list and now on the www-tag list.  
> 
> We discussed this at our f2f, both among ourselves:
> http://www.w3.org/XML/2005/02/xml-f2f-20050303-minutes.htm#xml-id
> and with the TAG:
> http://www.w3.org/XML/2005/02/xml-f2f-20050303-minutes.htm#tag-c14n
> 
> We are continuing with xml:id as it stands.
> 
> We will make C14N a separate task once our charter has
> been amended to allow that.
> 
> ACTION to Norm:  Do some work on the xml:id test suite
> to get it more usable.

Norm sent some email at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0023
and a sample of his implementation feedback at
http://www.w3.org/XML/2005/01/xml-id/xmlidfilter-report

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.

> 
> 7.5  Meaning of namespace.
> 
> This came out of xml:id and C14N, but is separable.
> 
> The XML Core WG should make the policy for adding 
> names to the xml namespace explicit in the namespace 
> document for this namespace
> 
> Henry suggested (revised) wording at:
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0018
> 
> We will approve this wording at this telcon.

Approved.

ACTION to Henry:  Update the xml namespace document
with the latest suggested wording.

> 
> 8.  Associating stylesheets--awaiting TAG action.
>
> 
> 9.  absolutivity of [base URI]
>     Norm has asked a question about the absolutivity of [base URI]:
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Feb/0031
> 
> We discussed this at our f2f:
> http://www.w3.org/XML/2005/02/xml-f2f-20050303-minutes.htm#base-uri
> 
> 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).

ACTION to Richard continue.

> 
> paul
> 
> [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/0019
> [7]
> http://www.w3.org/XML/2004/02/proposed-xml10-3e-and-xml11-errata.html
> [8] http://www.w3.org/XML/xml-V10-3e-errata
> [9] http://www.w3.org/XML/xml-V11-1e-errata
>

Received on Wednesday, 23 March 2005 16:37:26 UTC