W3C home > Mailing lists > Public > public-grddl-wg@w3.org > April 2007

Re: issue-base-param

From: Chimezie Ogbuji <ogbujic@ccf.org>
Date: Tue, 17 Apr 2007 13:51:36 -0400
To: "Jeremy Carroll" <jjc@hpl.hp.com>
cc: "GRDDL Working Group" <public-grddl-wg@w3.org>
Message-ID: <1176832296.15316.15.camel@otherland>

On Tue, 2007-04-17 at 14:04 +0100, Jeremy Carroll wrote:
> However, the base-param issues are not to do with XSLT usage, but to do 
> with GRDDL processing. A GRDDL processor, processes some documents, 
> invokes some transforms, and  processes some transform output.
> Either of the processing steps use base-params - but which URIs get 
> passed? 

I think this is only a problem for the processing steps which don't have
a notion of a Base URI in their model.  Primarily: XPath 1.0 and XSLT
1.0.  With regards to XPath 1.0 (i.e., in the normative statements where
we have XPath expressions against the source document), I think we only
have to introduce a consistent notion of a Base URI (which we resolve
all relative URIs in the source against) of the root node which is
equivalent to the Base URI of the document entity and cite XML Base
normatively.  I don't think there is any way around at least citing XML
Base normatively.

This would be consistent with the specifications which *do* cite XML Base.  Note that though XSLT 1.0 defines [1] 
its own notion of “ the Base URI of the document entity” it is rather under-determined (from the XML specification alone):

>From http://www.w3.org/TR/1998/REC-xml-19980210#sec-doc-entity

[[[
The document entity serves as the root of the entity tree and a starting-point for an XML processor. 
This specification does not specify how the document entity is to be located by an XML processor; unlike 
other entities, the document entity has no name and might well appear on a processor input stream without 
any identification at all.	
]]]

Whereas XML Base states:

[[[
The base URI of a document entity or an external entity is determined by RFC 2396 rules, namely, that the 
base URI is the URI used to retrieve the document entity or external entity.
]]]

It is worth noting that RFC 2396 gives us guidance on the 30X scenario and in particular supports (for instance)
 Jeremey's interpretation of relative URI references in http://purl.org/NET/erdf/ as requiring a resolution against
 http://research.talis.com/2005/erdf/

5.1.3. Base URI from the Retrieval URI:
[[[
Note that if the retrieval was the
result of a redirected request, the last URI used (i.e., that which
resulted in the actual retrieval of the document) is the base URI.
]]]	

It just puts a burden on the client to be aware of the Location header returned from the initial GET to the
 http://purl.org/NET/erdf/ (which returned a 302 status) 

With XSLT 1.0, we only have a problem if there isn't an xml:base attribute in the document or there is 
an xml:base which is not absolute (as Jeremy pointed out).  If there isn't an xml:base attribute, we 
supply the baseURI of the source document as the “the Base URI of the document entity“.  This is consistent 
with our base-param-issue resolution:

[[[
RESOLVED: Given that a base URI parameter is a parameter whose value is the base URI of the source document, 
the WG RESOLVES not to define a base URI parameter for transforms.  
]]]

It doesn't conflict with XSLT 1.0 (which is already rather unclear in this regard), and is consistent with XSLT 2.0,
 XML Base, and  RFC 2396.

> Do we respect xml:base attributes or not? 

If we cite XML Base normatively then it requires that we do.

> Which HTTP or other 
> protocol level indicators of base do we respect? 

RFC 2396, which gives kicks in if there is no indication of a base
within the document content.  It also gives guidance for protocol
redirection.

> Do we respect html 
> <base> elements within valid HTML?

This might be a bit controversial, but I believe by virtue of expressing
our normative sections in XPath, the language in XML Base which strongly
[2] suggests that future XML-based frameworks follow XML Base (instead
of HTML constructs) for specifying a base, and our charter which speaks
*first* (and foremost) about XML that we do *not* respect <base>
elements within XHTML (valid or otherwise).

> 
> Do either library functions:
>    embeddedRDF
> and
>    glean-profile
> respect xml:base and/or html base?

As XSLT 1.0 transforms they are not *required* to respect xml:base, but
they do have to respect an application-provided notion of the "base URI
of the document entity" - which our resolution provides.  They *can*
choose to explicitly match xml:base (or HTML <base>) attributes (as the
RDFa transform does).  

So, I don't think issue-base-param merits reopening (even given this
substantive discussion of it) - the resolution is consistent with the
precedent set by XML Base and RFC 2396 (going forward).  Even if we do
reopen it, I think citing XML Base, being clear about how we use XML
Base to determine the Base URI of the document entity, and being
consistent in requiring all relative URI resolution happens WRT to this
base should not put any significant risk on our schedule (any more than
we already have).

[1] http://www.w3.org/TR/xslt#base-uri
[2] http://www.w3.org/TR/xmlbase/#introduction

-- 
Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593
ogbujic@ccf.org


===================================




Cleveland Clinic is ranked one of the top 3 hospitals in
America by U.S.News & World Report. Visit us online at
http://www.clevelandclinic.org for a complete listing of
our services, staff and locations.


Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.
Received on Tuesday, 17 April 2007 18:16:10 GMT

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