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

Re: Appling inheritance rule to xml:base, was Re: FINAL minutes for the XML

From: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
Date: Wed, 15 Mar 2006 21:58:45 +0100
Message-ID: <44188005.4000900@iaik.tugraz.at>
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>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:33 GMT