- 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>
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 UTC