RE: XLink and Style

<SNIP/>

As an XLink /Fragments neophyte I am grappling with conceptual style
problems I see arising in my clients Web sites.  So let me ask a question by
using an example (If I am lucky it will generate some response):

A Wholesale Company (syndicator) makes its catalog available as a
well-formed and valid xml document with an associated style sheet.  The
style sheet incorporates product branding and corporate approved styles for
retailers.  The retailer (subscriber) has a business rule established with
the syndicator to use either the document as a whole or a fragment of that
document specific to their purposes.  The syndicator adds a new subset of
data which the subscriber is interested in.  An ICE transaction occurs
proffering an XLink to the fragment for embedding by the subscriber.  

All ICE does is proffer and accept syndication based on a preset business
rules schema.  The Fragment merely defines the parent document and does not
associate style to the FCS.  All XLink does is point to the fragment.  So I
see four options for the style: 
1)The style is manually incorporated into the business rule (and changed
manually) Note: this may be the included in the constraints file of an ICE
package??? 
2)It is passed as a part of the ICE package (ice-item or ice-package)(see
below)
3)It is passed as part of the XLink offered within the ICE package (Would a
simple or extended xlink be appropriate to use as a refrence point in an ICE
package?) 
4)It is incorporated as an externalref within the Fragment (see below)


Modified Sample of an ice package from http://www.w3.org/TR/NOTE-ice

<?xml version="1.0"?>
<!DOCTYPE ice-payload SYSTEM "../ice.dtd" [
    <!ENTITY % cm.item "comic-strip" >
    <!ELEMENT comic-strip (#PCDATA) >
    <!ATTLIST comic-strip
        author     CDATA    #REQUIRED
        copyright  CDATA    #REQUIRED
	  pubdate    CDATA    #REQUIRED
        numpanes   CDATA    #IMPLIED
        title      CDATA    #REQUIRED
	  style	 CDATA    #IMPLIED
    >
]>
<ice-payload ...
 <ice-response ...
  <ice-package ...
   <ice-item-group ...
    <ice-item
         item-id="431-1" 
         subscription-element="431-1" 
         name="Comic"
         content-filename="d.gif"
         content-type="application/xml"
    >
     <comic-strip
        title="Doones County"
        author="Gary Beathard"
        numpanes="3"
        copyright="United Tribune"
        pubdate="20010324"
	  style="../comics/doones.xsl">
PdXIWZQ8IiPLHtxqyjZFWt0hHrQcrjxAQ8VquFJS8vDC+
g4SsHSChBRUN0tTxS1wTuMC/242YYPBs87U8IkRlGu4G5
    . . .
M7qLNPuTNMlXc8G4sUgXc8dPdREbcFWnM9FndTgkwAAOw==
     </comic-strip>
    </ice-item>
   </ice-item-group>
  </ice-package>
 </ice-response>
</ice-payload>

Modified Sample Fragment from http://www.w3.org/TR/WD-xml-fragment#fcs
<f:fcs xmlns:f="http://www.w3.org/XML/Fragment/1.0">
      <f:extref type="text/xsl"
xmlns="http://www.oasis-open.org/docbook/DocbookSchema">
		http://www.oasis-open.org/docbook/docbook/3.0/docbook.xsl
	</f:extref>
 
<f:parentref>http://www.acme.com/~me/mydocs/mybook.xml</f:parentref>
    <book>
      <part>
        <chapter>
          <sect1/>
          <sect1>
            <orderedlist numeration="arabic">
              <listitem/>
              <f:fragbody/>
            </orderedlist>
          </sect1>
        </chapter>
      </part>
    </book>
  </f:fcs>

<Paul>
I don't think that the distinction between presentation and content is
usually so complicated. Typically I have a problem to solve -- if I embed
some information it limits the usefulness of the information. If I impose
the information externally then the information is more widely useful.
Typically that information is presentation (though there are other types of
redundancy).
</Paul>
<Simon>
My concern here is that while the nature of an XLink used in a particular
context may be clear (content, presentation, metadata, something else), the
relationship between linking in general and style sheets is not likely to be
as clear, and the presentation/content distinction isn't always as simple as
it might seem.

I'd rather focus on the problem solving than 'first principles', and it
sounds like you agree.
</Simon>
<SNIP/>

Daniel L. Koger
Senior Web Developer
BEST Consulting
Phone
Work:	      425.202.8206
Main:	      425.814.8104
Fax:	      425.814.8108
Email
Work:		dkoger@bestnet.com 
Home:		dkoger@oz.net
Generic:	dkoger@hotmail.com
Web
Work:		http://www.bestnet.com
Home:		http://www.oz.net/~dkoger

If you can't reach me, you aren't trying...
***************************
Don’t go around saying the world owes you a living.  The world owes you
nothing. It was here first.

Mark Twain

Received on Thursday, 15 April 1999 12:46:51 UTC