Subject: template for XLink processing From: "Vun Kannon, David" <dvunkannon@xxxxxxxx> Date: Tue, 2 Nov 1999 12:03:05 -0500 |
Even though XLink is still a WD, I'm trying to work out some of the implications. It seems to me that a transform should try to respect the show and actuate attributes, at least where actuate="auto", meaning that the link should be traversed automatically. Assuming actuate="auto" for the moment, the choices for show are "new", "replace", and "parsed". "New" in the UI context means show the content in a new browser window. Should a new transform process be spun up (new source document, same stylesheet)? "Replace" in a UI means (obviously) replacing the first content with the new content. Should the transform kill itself, trash the result tree and proceed as in the "new" case with a replaced source and same stylesheet? Most interestingly, "parsed" seems to be an inclusion mechanism. Should the transform use the document() function or similar techniques to extend the source node tree with new nodes? My interest is drawn to these questions because I am working on a DTD currently that does not use containment to represent structure. Rather, documents are sets of atoms and arcs. Atoms contain content, arcs are empty linking elements. My current design for arcs looks like: <!ELEMENT Arc EMPTY > <!ATTLIST Arc from IDREF #REQUIRED to IDREF #REQUIRED > This is very similar to XLinks Arc element. The difference is that XLink Arcs are about traversal semantics as well as about structure. If I adopt XLink in my design, I feel that the correct actuate value is "auto". I'm not sure about show and what should be done with it. Cheers, David vun Kannon ***************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter. ***************************************************************************** XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: MIF output from XT, Christopher R. Maden | Thread | Re: template for XLink processing, Paul Prescod |
RE: Dependency Sorting, first of ki, Kay Michael | Date | RE: MIF output from XT, Mike Brown |
Month |