RE:

Hi Paul,

-----Original Message-----
From: Paul Grosso [mailto:pgrosso@arbortext.com]
Sent: Wednesday, July 26, 2000 12:29 PM
To: John Boyer; Www-Xml-Linking-Comments@W3. Org
Cc: XML DSig
Subject: Re:


What does C14N do about relative URIs in external entities in the
absence of any xml:base

<john>
c14n is not a big consumer of xml:base per se.  It will use it the same way
that Xpath will use it, namely for resolving relative URIs in namespace
declarations, unless the W3C decides  to stick with the Namespaces
recommendation and patch XPath so that relative URIs are not absolutized (in
which case, c14n will not directly use xml:base at all).
</john>


and how does xml:base cause a problem that
isn't already there with external entities?

<john>
The problem isn't with any functionality that c14n needs, but rather with
the interpretation of a document being different from the canonicalized
document.  XML Base is (or will be) a recommendation that all XML
applications should resolve relative URIs *whereever they may be in the
application content* by using the rules given in xml:base.

An application uses an XML processor to obtain XML content, so the
application is unlikely to know whether the content was the result of an
external entity or an internal entity because this information is not
reported to the application.

So, suppose the application has an element E containing char data that the
application knows is a relative URI.  Further, suppose an ancestor element
of E contains an xml:base attribute.  How does the application know whether
or not to apply the xml:base to the relative URI?

See below for more...
</john>

See also some of the following:

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0056
http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0047
http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0062

and the rest of the many messages in this archive on this issue.

<john>
In these emails, you rationalize the fact that xml:base should not apply to
external entities by using the following citation from XML 1.0 from section
4.2.2 [1]:

"Unless otherwise provided by information outside the scope of this
specification (e.g. a special XML element type defined by a particular DTD,
or a processing instruction defined by a particular application
specification), relative URIs are relative to the location of the resource
within which the entity declaration occurs"

[1] http://www.w3.org/TR/REC-xml#sec-external-ent

I have several comments about this.

Firstly, the citation justifies a *default* base URI, so there is no
justification for explicitly cutting off xml:base, which is used to override
the default established by the citation.

Secondly, the citation explicitly allows for the possibility that overrides
to this default behavior are possible.  Therefore, the citation
substantiates the possibility that xml:base could be applied to descendant
content derived from external entities.  I do not see the citation
justifying or mandating that xml:base settings should not apply to content
derived from external entities.

Thirdly, I provided a compelling citation from the XML 1.0 spec that seems
to override your interpretation of [1].  The following can be read at [2]:

[2] http://www.w3.org/TR/REC-xml#included

"4.4.2 Included

An entity is included when its replacement text is retrieved and processed,
in place of the reference itself, as though it were part of the document at
the location the reference was recognized. The replacement text may contain
both character data and (except for parameter entities) markup, which must
be recognized in the usual way, except that the replacement text of entities
used to escape markup delimiters (the entities amp, lt, gt, apos, quot) is
always treated as data. (The string "AT&amp;T;" expands to "AT&T;" and the
remaining ampersand is not recognized as an entity-reference delimiter.) A
character reference is included when the indicated character is processed in
place of the reference itself."

The key phrase is *as though it were part of the document at the location
the reference was recognized*.  The issue I'm raising is that applications
do not know that content was derived by internal or external means because
the content appears as though it were part of the document.  Therefore,
application cannot use of xml:base when its setting is given by an ancestor
element.

John Boyer
Development Team Leader,
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>
</john>


paul

At 12:03 2000 07 26 -0700, John Boyer wrote:
> I realize this is  after the last call period, but the matter was brought
to my attention after the  last call period for XML base.  XML base is
restricted from applying to external entities.  However, when you c14n a
document, the external entity content is brought into the document, so
xml:base will apply to it.    Right now, I have  language in c14n that
propagates xml:base to descendant elements in the case of  document
subsets, but the problem above occurs even when one does a c14n of the
whole document.  I think c14n is  doing the right thing in that it is
consistent with what xml:base should  do:  the entities are no longer
external, so xml:base attributes from  ancestors should apply to them.  It
think the problem is that the meaning  of the content is changed based on
where we get it from.  We have no way of  retaining information on content
derived from external entities.  In  particular, the feature seems to
contradict the language of section 4.4.2 of XML  1.0:  "An entity is
included when its replacement  text is retrieved and processed, in place of
the reference itself, as though  it were part of the document at the
location the reference was recognized.  "  Since the  replacement text
should be treated 'as though it were part of the document', we  should not
introduce an attribute into the xml namespace that violates this  concept.
>

Received on Wednesday, 26 July 2000 19:13:21 UTC