W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > August 2004

Minutes for XML Core WG telcon of 2004 August 18

From: Paul Grosso <pgrosso@arbortext.com>
Date: Wed, 18 Aug 2004 12:12:56 -0400
Message-ID: <9C92C0983E60A74380C585F1EB5D186F018607CF@ati-mail01.arbortext.local>
To: "XML Core WG" <public-xml-core-wg@w3.org>

Lew   xx:10

[7 organizations (8 with proxies) present out of 12]

Daniel, proxy to the chair

Absent organizations
Oracle (with regrets)
U of Edinburgh (with regrets)
Daniel Veillard (with regrets, proxy to the chair)
François Yergeau 
John Cowan 

Our next telcon will be next Wednesday, August 25th.   

Henry sends regrets for next week.

> 1. Accepting the minutes from the last two telcons [3a,b] and the
> current
>    task status [2] (have any questions, comments, or corrections
>    ready by the beginning of the call).


> 2. Miscellaneous administrivia.
> 3. Problem with xml:space in the Schema document for the XML namespace
> Masayasu Ishikawa <mimasa@w3.org> sent us email on this at:
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2004Jul/0019
> Norm thinks Mimasa is correct; we should not provide a default for
> xml:space.
> Glenn agrees.  Richard agrees.
> We should remove the default for xml:space from the schema.
> We have CONSENSUS that we should remove the default from xml:space,
> but we'd like to wait until Henry is back to be sure.
> ACTION to Henry (when he returns):  Comment and perhaps fix 
> the schema.

Henry questioned our decision.  Norm and Henry discussed it
a bit; Richard and Glenn were absent.

ACTION to Henry:  Research whether Mimasa is correct in that he
cannot now make xml:space fixed and either Reply to him telling
how to do it or to the WG otherwise.
 Already done: 

ACTION to Henry:  Check his schema collection to see if anyone 
is using xml:space in an interesting way and see if this leads
us to want to change the current declaration of xml:space.

> 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]. 
> PE 130 Missing paren in section 5.2 in XML 1.1
> ----------------------------------------------
> Editorial.  We should add the missing paren (was in 3rd Ed).
> CONSENSUS to do so.
> ACTION to Francois:  Put into countdown until August 11.
> PE 131 Space or S in XML decl.
> ------------------------------
> Commentor says we use Space in the XML decl, but S elsewhere.
> Actually, XML decl is (correctly) using S, and S is just the 
> same as in
> XML 1.0.
> So the bug is that in SDDecl, it refers to x#20+ instead S:
> http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-SDDecl
> We had CONSENSUS this was an editorial oversight, and that we should
> change x#20+ to S in the SDDecl production.
> ACTION to Francois:  Record the above resolution and put into 
> countdown.

The WG approved both PEs for final resolution.

ACTION to Francois:  Process both PEs as Errata as described above.

> 5. Namespaces in XML.
>   ACTION to Richard:  Produce a draft for NS1.0 2nd Ed.
> 6. Xinclude CR was published April 13 at:
>    http://www.w3.org/TR/2004/CR-xinclude-20040413
>    The updated test suite cover page is at
>    http://www.w3.org/XML/Test/XInclude/ 
> The PR-ready draft is at:
> http://www.w3.org/XML/Group/2004/07/PR-xinclude/
> The public DoC (aka latest issues list) is at:
> http://www.w3.org/XML/2004/07/ExIT-xinclude/issues.html
> At the top, this document says it's a DoC for the 3rd XInclude CR.
> Are we really at the third CR, or just the second?
> Am I reading the DoC correctly to say that we have closed all issues?
> Are there any "closed" issues for which we have rebuttal we wish to
> discuss?
> In the DoC, I don't understand "Ack" column of the table.  What does
> "review reply unaddressed" mean?

We discussed the details of this document a bit and decided
that we just had to touch on the "Reviewer reply unaddressed"
ones, xi-2 and xi-12.

> I thought we got some push back from Elliotte that requires that we
> indicate review non-acceptance of our resolution, but I don't see that
> reflected in the DoC.

xi-2 : Syntactically incorrect IRIs in href attributes
We decided to leave IRI validation up to the implementation.
ERH objects to doing so, but Daniel's implementation is a
case in point where IRI validation is not feasible.

So the WG reconfirms our previous decision.

xi-12 : xml:lang implementation report
ERH would prefer that we drop the language property from 
xinclude processing.  Specifically:
  I see no need to introduce a new property for the element
  information item to have the desired effect. It would be
  much simpler and more consistent with existing specs and
  APIs to define this purely in terms of attributes.

The WG's understanding of the request from I18N and the TAG
in this area leads us to reconfirm our previous decision.

ACTION to Jonathan:  Augment the DoC to point to our 
reconfirmations above.

> At 
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2004Jul/0025 
> Richard had sent a format for submitting test reports and an XSLT 
> to convert the report to an HTML page.  He also included his actual
> results.
> We still need implementation feedback from Daniel and 
> Elliotte (and any others from who we can).
> Richard sent Elliotte an email on how to present his results; any
> response?
> ACTION to DV:  Provide a table giving results (using 
> Richard's files) of
> running the test suite on your implementation.
> ACTION to Paul:  Write a PR request once we are ready to exit CR.

ACTION continued, for next week.

> 7. xml:id.
> We should say that the values of xml:id must be
> Names according to the XML version of the document.
> ACTION: xml:id editors to update the draft to allow XML 1.0 and XML
>         1.1 Names as appropriate.
> We need to get into processing xml:id comments and producing a new
> draft.
> ACTION to Daniel:  Work toward producing a new draft.
> Norm may have some cycles to work on this after mid-August.

Relaxing the constraint that there be one ID per element.

We currently say that multiple ids are an error.  

Schema 1.1 is thinking of allowing multiple ids (though opinion
is still split on this).

We want to make sure that the xml:id spec is agnostic wrt whether 
there is more than one thing of type id on one elemnt, as this is 
a property of the validation mechanism.  

Currently, the spec says nothing in this regard, so it is, in fact,
agnostic.  Therefore, we have no action.

So the reply to the comment is that the xml:id spec has no such
constraint, so there is nothing to relax.

ACTION to DoC maintainer:  Record this resolution and reply to
the commentor.

ACTION to Norm:  Raise a new issue about whether we need to fix 
the references property as far as the behavior when no xml:id 
declaration is available.

ERH asking for something simpler.

We have thought about this a lot and can't think of anything
simpler that works.  We need to work through the infoset, and
we believe this is simpler than enumerating the behavior of
all existing APIs and interfaces.

Norm had a suggested rewording to simplify the spec (collapsing
section 4.1, 4.2, 4.3 and/or making them non-normative appendices).

ACTION to Norm:  Produce such a draft after getting the latest
sources from Daniel.

> [1] http://www.w3.org/XML/Group/Core
> [2] http://www.w3.org/XML/Group/Core#tasks
> [3a] 
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2004Jul/0034
> [3b] 
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2004Aug/0003
> [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
> [12] http://lists.w3.org/Archives/Member/chairs/2004AprJun/0058.html 
Received on Wednesday, 18 August 2004 16:13:52 UTC

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