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

Minutes for XML Core WG telcon of 2005 April 20

From: Paul Grosso <pgrosso@arbortext.com>
Date: Wed, 20 Apr 2005 12:00:45 -0400
Message-ID: <F13E1BF26B19BA40AF3C0DE7D4DA0C030429D87B@ati-mail01.arbortext.local>
To: <public-xml-core-wg@w3.org>

 Glenn  xx:10
 Dmitry  off at xx:52
 John  xx:17

[8 organizations (9 with proxies) present out of 10]

Daniel (proxy to the chair)

Absent organizations
Daniel Veillard with regrets, proxy to the chair
Lew Shannon

> 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 has been approved.
> The Call for Participation is out, and everyone on the WG
> has to have their AC rep submit their name as a member in
> the rechartered WG by May 20th:
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Apr/0006

So noted.

> Richard reviewed the 
> XPath 2.0/XQuery 1.0 Data Model document that is at:  
> http://www.w3.org/TR/2005/WD-xpath-datamodel-20050211/
> Richard's review is at:
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Apr/0014
> There is also an issue about what the types are in the data model:
> the schema types or another system that is similar.  Henry and
> Richard point out the type hierarchy in this data model spec
> is not quite the same as in the XML Schema spec.
> ACTION to Richard:  Augment the earlier email with respect
> to the above issue and send them in as XML Core WG comments.

ACTION to Richard, continued.

> 3.  XLink update.
> Our WG Note "Extending XLink 1.0" has been published:
> http://www.w3.org/TR/2005/NOTE-xlink10-ext-20050127/
> Norm's latest editor's draft of XLink 1.1 is at
> http://www.w3.org/XML/Group/2004/xmlcore/xlink11/
> John has provided a relaxng schema. 
> Henry has provided an XML Schema.
> Paul has gotten Director's approval for publishing this
> as a first WD:
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Apr/0035
> (which contains a suggested addition to the SOTD from TBL).

Norm has updated the SOTD accordingly.

> We expect to VOTE TO PUBLISH this as a first WD during
> this week's telcon--be ready!

Norm says the draft is ready except for the XML Schema
that Henry is planning to send later today.

Also, John thought xlink could not be nested, but Norm
thinks xlink can be nested, and he doesn't wish to change
this between XLink 1.0 and 1.1.  John now agrees that
links can be nested, so we will leave the wording as
Norm now has it.

Henry has sent in a new XML Schema, and John will
send in a new relaxng schema.

The WG had unanimous CONSENSUS to publish XLink 1.1 
as a first WD:

ACTIN to Paul: Send in the publication request for
XLink 1.1 to be published as a first WD (tomorrow

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

Richard sent email:

But he points out that he doesn't suggest we make this
change until and unless we change the references to 2396
to 3986.

Richard suggests we defer this erratum for now.

CONSENSUS to defer this erratum for now.

ACTION to Francois:  Make a PE for this topic and record
Richard's email but note that we will defer the resolution
of this PE until further notice (e.g., when we change the
references from 2396 to 3986).

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

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

> 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 Norm:  Suggest actual wording.

CONSENSUS to use Norm's new paragraph from

ACTION to Daniel:  Update the XInclude PE document to
reflect Norm's new paragraph.

> 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 Norm:  Reply to the commentor.

Norm sent email for PEX1 and PEX2 at:

ACTION to Norm:  Send on the response to the commentor.

ACTION to DV:  Update the PE doc.

> PEX3 What is an error (subcase on accept attribute value)
> --------------------------------------------------------
> ACTION to DV:  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
> One can have "+xml" on a mime type that is neither
> XML or text, and we don't say anything about that
> in XInclude.
> Norm thinks we should say XInclude can work with "+xml"
> mime types.  
> But then image/svg+xml doesn't have a charset.
> ACTION to Francois:  Take a look at this for next week.

Francois sent email:

He thinks the XInclude spec is clear enough in that RFC 3023
already says *+xml are of type XML.  As far as svg+xml which
doesn't have a charset parameter, one just does the usual
fallback for determining charset, so once again, we don't 
need to change the spec.

CONSENSUS to leave the spec as is and reply to the commentor
along the lines of Francois' email.

ACTION to Francois:  Reply to the commentor.

ACTION to DV:  Update the PE doc.

> PEX14 What if encoding is not an EncName?
> -------------------------------------------
> ACTION to DV:  Close this as a dup of PEX3 and PEX7.
> PEX15 XPointers with percent escapes: what type of error?
> -----------------------------------------------------------
> See
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0033
> JohnC sent email saying:
>   There is no issue of any sort of error.  We simply need to insert
>   a sentence like "%-escaping is not done in XPointers, so '%' is
>   simply an ordinary character in the value of the xpointer 
> attribute."
> ACTION to Daniel:  Update the PE document with these resolutions
> and update the spec accordingly.
> 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
> Richard put his implementation report at
> http://www.w3.org/XML/2005/01/xml-id/rxp-report.html
> Richard had some questions on Norm's latest test suite.
> On the last test, Norm fails because XSLT can't do it.
> Norm gets a space in it that shouldn't be there.  When
> Richard runs it, he gets the empty string for the result.
> ACTION to Norm:  Investigate what should happen on this
> last test.

ACTION continued.

> ACTION to DV:  Run your implementation on the 
> test suite and produce some feedback report.
> We discussed changing wording about errors so that an xml-id
> processor doesn't need to report errors *to the application*.
> In Section 6 Errors, we currently say:
>   A violation of the constraints in this specification
>   results in an xml:id error. Such errors are not fatal,
>   but must be reported by the xml:id processor to the
>   application invoking it.
> ACTION to Richard:  Suggest some rewording for this and
> pass it by ERH.

ACTION continued.

Dan Connolly raised a new issue: he wants us to have tests
demonstrating xml:id working with CSS (and the DOM, etc.).

Norm isn't sure how to test this.  It requires a change to
CSS implementations.

ACTION to Paul:  Raise this issue at the XML CG and/or CSS
WG to see what can be done.

> 8.  Associating stylesheets--awaiting TAG action.
> ACTION to Henry:  Raise this issue at the TAG level
> (or just bring it back to us).

Henry noticed that the HTML CG has run into the same issue.
There is an interaction between media types and secondary
resource, and there appears to be no consensus on the HTML CG
as to what should be the case.

Henry asked the HTML CG if they felt this issue should be
taken to the TAG, but being as he just asked them, there 
hasn't yet been a response.

ACTION to Henry:  Continue to see if this issue should
be brought to the TAG.

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

Richard sent email at:

ACTION to Richard:  Send on the email to www-tag.

> 10.  XML Validity and DTD dependence.
>   Rich Saltz started the discussion at
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Apr/0026
> and there have been several responses.
> [When you respond, be sure to leave Rich's address
> explicitly cc-ed (he is able to post to the list,
> but he does not get list email unless his address
> is given explicitly).]

No one on the WG supports Rich, and some of us (Norm)
doesn't really understand just what Rich is requesting
in terms of an actual change.  But the discussion isn't
over just yet.

> 11.  XInclude, schema validity-assessment, xml:base and xml:lang
> Henry kicked this off at:
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Apr/0039

We didn't have much time to discuss this topic on this telcon,
but Norm and Henry both lean toward making it an issue for
the XML Schema WG, so we are waiting to hear from them.

> [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/2005Apr/0023
> [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, 20 April 2005 16:01:21 UTC

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