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

Re: remove xml-stylesheet appendix?

From: Chimezie Ogbuji <ogbujic@ccf.org>
Date: Fri, 06 Apr 2007 09:57:48 -0400
To: "Dan Connolly" <connolly@w3.org>
cc: "GRDDL Working Group" <public-grddl-wg@w3.org>
Message-ID: <1175867868.9871.38.camel@otherland>

I would be against removing it.  Although they are not enforced
'formally', xml-stylesheet processing instructions are supported by a
large number of web agents and XML processors.  In addition, I think it
is in the interest of GRDDL to be clear about how its use of XML
pipleines to produce content for machine consumption (faithful
rendition) differs significantly from the precedent of using XML
pipelines to produce content for human consumption (the whole content
versus presentation pattern: docbook -> PDF,HTML, etc..).

GRDDL aware-agents which piggy-back XML processors may be in for a
surprise if the underlying XML processor, applies xml-stylesheet
processing instructions by default (some do).  An explicit health
warning is prudent, even if we explicitly mark it as informative.

I'd prefer clarifying the text rather than deleting it or marking it as
informative (I assumed that its place in the appendix suggests that is
informative).  A new first paragraph:

[[[
The xml-stylesheet processing instruction[STYPI] is generally deployed
for automated presentation processing. This type of link is different
from links to GRDDL transformation algorithms, which are intended to
facilitate the extraction of RDF as a faithful rendition [#sec_rend] of
the source.  The former is geared more for human consumption while the
latter is primarily for machine consumption. 

Document authors who wish their documents to be unambiguous when used
with GRDDL should avoid using xml-stylesheet processing instructions as
their use may interfere with transforms nominated by GRDDL for the
production of GRDDL results in the same source document.
]]]

The last part of the above was added with language that ended up having
to contend with statements made in the faithful-infoset sections and the
new health warnings added about DTD's and entities, so I tried to keep
the tone consistent.  

The second paragraph (from the original) is not true as there are at
least three examples of XSLT processors which support this: 4Suite,
Saxon, and MSXML (I'm not sure why this did not come to my attention
before).  

[[[
Also, parsing the content of processing instructions is not supported by
XML tools such as XSLT processors, and grounding processing instructions
in URI space is not as straightforward as using namespaces with
attributes.
]]]


I'm not sure can suggest a change for that second part, so my vote is to
delete it.  Dave's concern seems to be about wandering into
implementation advice.  I don't think a health warning about possible
clashing of transform nomination WRT to xml-stylesheet applies, but a
(false) statement about support of xml-stylesheet along with a critique
of them doesn't seem very appropriate, in retrospect.  Especially
considering the language of the failthful-infoset paragraph suggests the
WG has taken a stance of being silent about XML processors.


-- 
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 Friday, 6 April 2007 13:58:01 GMT

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