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

Minutes for XML Core WG telcon of 2005 March 30

From: Paul Grosso <pgrosso@arbortext.com>
Date: Wed, 30 Mar 2005 11:40:28 -0500
Message-ID: <F13E1BF26B19BA40AF3C0DE7D4DA0C0303E2BE1E@ati-mail01.arbortext.local>
To: <public-xml-core-wg@w3.org>

Daniel  xx:18

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


Absent organizations
IBM (with regrets)
University of Edinburgh (with regrets)
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).


> 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:
> 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 the telcon to 
> the XML Core WG outlining any issues in these documents 
> that may be of interest to the XML Core WG.

Not all the documents have quite been released.

ACTION to Dmitry continued--due by end of this week.

> 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--due by end of this week.

> 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."
> JohnC did a pass and saw nothing for XML Core WG.
> Paul still hopes to look at it.

ACTION to Paul:  Review the CDF document by end of this week.

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

> We had a question about the XML Test Suite arise; see
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0037

Awaiting response from Richard.

> 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
> 6. Xinclude Rec was published 2004 December 30 at:
>    http://www.w3.org/TR/2004/REC-xinclude-20041220/
> Our XInclude potential errata document is at:
> http://www.w3.org/XML/2005/01/proposed-xinclude-errata
> See
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0029
> 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"
> -------------------------------------------
> See
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0032
> PEX6 parse="text" and Byte-Order Mark
> -------------------------------------
> What are the *{LE,BE} encodings?

The answer is:  UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE.

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

Francois suggests making it a fatal xinclude error if
the XInclude processor actually goes to try to use an
encoding value and that value doesn't conform to the
syntax of EncName.

What do others think?

> PEX15 XPointers with percent escapes: what type of error?
> -----------------------------------------------------------
> See
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0033

Henry raised the issue of the problems of xml:base, XML Schema, 
and XInclude; that is, that use of XInclude might require
introduction of xml:base in a document whose schema doesn't
allow xml:base.

Given that all are Recommendations, no one could think of
a good resolution here (short of saying that the schemas
in question should be modified to allow xml:base).

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

Norm sent email to ERH.

> 8.  Associating stylesheets--awaiting TAG action.

ACTION to Henry:  Raise this issue at the TAG level
(or just bring it back to us).

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

> [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
> [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, 30 March 2005 18:15:25 UTC

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