Minutes for XML Core WG telcon of 2005 March 16

Attendees
---------
Paul 
Glenn
Arnaud (partial)
Dmitry
Norm 
Richard
Henry
Daniel  
François 

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

Regrets
------- 


Absent organizations
--------------------
NIST 
Lew Shannon
John Cowan

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

ACTION to Richard continued.

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

The chair requests volunteers to review this document.

Please reply via email if you can do so.

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

> Richard pointed out a namespace comment at
> http://lists.w3.org/Archives/Public/xml-names-editor/2004Dec/0000
> which requests something which is almost a different kind of schema.
> 
> We discussed this at our f2f.  We don't this is within 
> the scope of the namespace spec or our WG charter.
> 
> ACTION to Richard:  Respond to this comment (on the 
> xml-names-editor list).

Done.

> 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

ACTION to DV continued.

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

ACTION to DV continued.  Paul may pitch in.

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

ACTION to Norm continued.

> 
> 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
> 
> ACTION to Henry:  Suggest modifications to the XML
> namespace document and send to the XML Core list
> for approval.

Henry suggested wording at:
http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0017

We word-smithed it a bit, and Henry will resend
the latest wording to the list, and we will plan
to approve it at our next telcon.

> 
> 8.  Associating stylesheets
>     We have had several requests to issue some clarifications
>     on use of fragment identifiers in URIs to referenced
>     stylesheets:
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Feb/0022
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Feb/0030
> 
> We discussed this at our f2f, both among ourselves:
> http://www.w3.org/XML/2005/02/xml-f2f-20050303-minutes.htm#xml-stylesheet-pi
> and with the TAG:
> http://www.w3.org/XML/2005/02/xml-f2f-20050303-minutes.htm#tag-sspi
> 
> If anything, our discussions expanded the scope of the issue.
> 
> Henry will probably raise some form of this as a TAG issue; 
> the WG plan is to wait for the TAG to take the heat. 
> 
> Paul will ensure we have coordination with the Hypertext CG on this.
> 
> 
> 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. 
> 
> We decided that the Infoset references xml:base which 
> references RFC 2396 which makes base URI always absolute, 
> so although some of us prefer making it explicit in the 
> Infoset, we DECIDED not to bother.
> 
> Henry explains his view that we need to allow frag ids 
> in [base URI]. However, 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 continued.

> We asked if we should change [base URI] to [base IRI], but
> there are various issues to decide here, and we decided to 
> hold off on doing anything here for now.

We have to wait to see how IRIs are adopted before
considering doing this.

> 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/0010
> [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, 16 March 2005 16:34:01 UTC