- From: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
- Date: Wed, 15 Mar 2006 21:58:45 +0100
- To: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
- Cc: "Henry S. Thompson" <ht@inf.ed.ac.uk>, daniel@veillard.com, John Boyer <boyerj@ca.ibm.com>, public-xml-core-wg@w3.org, Peter Lipp <peter.lipp@iaik.tugraz.at>, Martin Centner <martin.centner@iaik.tugraz.at>
- Message-ID: <44188005.4000900@iaik.tugraz.at>
A minor fix please see below. Konrad Lanz wrote: > Dear all, > > I quickly browsed the specs and tried to fix the issue related to > [xml:base <http://www.w3.org/TR/xmlbase/#resolution>] and > [Canonical XML <http://www.w3.org/TR/xml-c14n>]. > Hoping I haven't oversimplified something I think we could specify > a "join URI function" by referring to > [RFC 2396 <http://www.ietf.org/rfc/rfc2396.txt>] section 5.2 skipping > steps 1 - 5 and performing step 6) only and amending it as follows, > thus appending a relative URI (rel-uri-2) to any URI (uri-1). > > a) All but the last segment of the *URI's (uri-1)* path component > is copied to the buffer. In other words, any characters after > the last (right-most) slash character, if any, are excluded. > > b) The relative *URI's (rel-uri-2)* path component is appended to > the buffer string. > > c) All occurrences of "./", where "." is a complete path segment, > are removed from the buffer string. > > d) If the buffer string ends with "." as a complete path segment, > that "." is removed. > > e) All occurrences of "<segment>/../", where <segment> is a > complete path segment not equal to "..", are removed from the > buffer string. Removal of these path segments is performed > iteratively, removing the leftmost matching pattern on each > iteration, until no matching pattern remains. > > f) If the buffer string ends with "<segment>/..", where <segment> > is a complete path segment not equal to "..", that > "<segment>/.." is removed. > > g) *If the resulting buffer string begins with > "<scheme>://<authority>/" followed by one or more complete path > segments of "..", then the resulting URI is considered to be > in error and Implementations SHOULD indicate this error and > fail, > if however there are no "<scheme>:<authority>/" components, the > result is a relative URI starting with a relative path. > Albeit if processing continues Implementations MUST handle this > by retaining the leading ".." complete path segments in the > resulting path (i.e., treating them as part of the final URI > e.g. ../../<segment>/<segment> )*. > > > We should also consider referring to [RFC 3986] > <http://www.ietf.org/rfc/rfc3986.txt> Section 5.2.3 Merge Paths, which > is even simpler ;-). > > Now follows a proposal for amending text in [C14n > <http://www.w3.org/TR/xml-c14n>] as follows : > > 2.4 Document Subsets > > Definition: > > * Simple heritable attributes are attributes that have a value that can > be redeclared only. This redeclaration is done by supplying a new value > in the child axis. Simple heritable attributes are xml:lang and > xml:space. > > * Joint heritable attributes are attributes that cannot only be > redeclared, but also have values that are to be interpreted by some > function depending on attributes of the same name in the parent axis. A > Joint heritable attribute is xml:base. > Joint heritable attributes need a "bequeath function" that pass only > their quintessential asset to their inheriting attributes of the bearing > element's on the child axis' .In the case of xml:base the "bequeath > function" is the "join URI function" (see above) taking any URI joining > a relative URI after it's last slash and then normalizes the result. > > > [...] The processing of an element node E MUST be modified slightly when > an XPath node-set is given as input and the element's parent is omitted > from the node-set. The method for processing the attribute axis of an > element E in the node-set is enhanced. All element nodes along E's > ancestor axis are examined for nearest occurrences of heritable > attributes in the xml namespace, such as the attributes *xml:lang, > xml:space and xml:base* (whether or not they are in the node-set). From > this list of attributes, remove any simple heritable that are in E's > attribute axis (whether or not they are in the node-set. Joint heritable > attributes can only be removed from the list if the their nearest > occurrences of the corresponding heritable attribute (xml:base) along > E's ancestor axis will also be rendered, otherwise the attribute remains > after it's value has been fixed using a "bequeath function" . Then, > lexicographically merge this attribute list with the nodes of E's > attribute axis that are in the node-set. The result of visiting the > attribute axis is computed by processing the attribute nodes in this > merged attribute list.[...] > > best regards > Konrad > > Henry S. Thompson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > ht should have written: > > > > <a> > > <b xml:base="test/"> > > <c xml:base="test"/> > > </b> > > </a> > > > > with the 'b' being clipped out, we get > > > > <a> > > <c xml:base="test/test"/> > > </a> > > > > - -- > > Henry S. Thompson, HCRC Language Technology Group, University of > Edinburgh > > Half-time member of W3C Team > > 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 > > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > > URL: http://www.ltg.ed.ac.uk/~ht/ > > [mail really from me _always_ has this .sig -- mail without it is > forged spam] > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.6 (GNU/Linux) > > > > iD8DBQFEGEeikjnJixAXWBoRAqrDAJ9SjWo5ia3ZY71qIS/0Wyb+A3G1wgCeL1h0 > > t1xtupkoi1t9e1/Jg4lumtU= > > =drcN > > -----END PGP SIGNATURE----- > > > > > -- Konrad Lanz, IAIK/SIC - Graz University of Technology Inffeldgasse 16a, 8010 Graz, Austria Tel: +43 316 873 5547 Fax: +43 316 873 5520 http://www.iaik.tu-graz.ac.at/aboutus/people/lanz http://jce.iaik.tugraz.at
Received on Thursday, 16 March 2006 00:44:21 UTC