Lists Home |
Date Index |
- From: "Roger L. Costello" <firstname.lastname@example.org>
- To: "email@example.com" <firstname.lastname@example.org>
- Date: Thu, 05 Aug 1999 15:14:34 -0400
Roger L. Costello wrote:
> Suppose that I have an XML document that is created by assembling
> XML data from various sources, using XML Link (with show="embed").
> Such a document raises interesting questions with regards to the XML
> schema for that document. Does the schema describe the structure of
> the document *after* the embeddding process has occurred (post-embed),
> or, does the schema describe the structure of the document *before*
> the embedding process has occurred (pre-embed)?
Ronald Bourret wrote:
> Interesting question. The schema specification does not answer it.
> However, it is really a question for the XLink folks, as it applies
> to DTDs as well as schemas. I doubt there is a simple answer, as both
> cases are useful.
Yes, I agree. This issue should be resolved with the XLink spec. By
properly defining the attributes of the link then applications such as
XML parsers will know definitively whether it should validate pre- or
post link resolution.
Paul Prescod wrote:
> The latest version of XLink does not have show='embed'.
I just took a look at the latest version of the XLink spec. In section
4.3 it says:
"There are two attributes associated with behavior: show and actuate.
The show attribute defines how the remote resource is to be revealed to
the user. It has three options: new, parsed, and replace. ... The parsed
option, relating directly to the XML concept of a parsed entity,
indicates that the content should be integrated into the document from
which the link was actuated."
The way that I read this, while it's true that there is no longer a
show='embed', there is a show='parsed' which has the exact same
"Simon St.Laurent" wrote:
> I pushed on this issue a few times in the XLink group and was
> consistently told that XLink material wasn't genuinely 'embedded',
> only referenced, and that it therefore had no impact on the target
> schema or style sheet. While I'm still not 100% convinced that this
> always makes sense, I'm at least 75% there.
I agree that the link contents are not truly embedded. However, as was
shown with my stocks example (and I can show many other examples, such
as merging dynamically generated weather reports from different parts of
the world), there is clearly utility in providing the abstraction that
the XML document contains the embedded text (and not links). We need a
link behavior which gives us the ability to specify that applications
should treat the link abstractly as if the link contents are truly
embedded (i.e., applications can't tell the difference).
In summary, it's clear to me that the ability to embed content
dynamically using XLink is important and the behavior of this
functionality must allow the user to specify that applications should
treat the link abstractly as if the link contents are truly embedded
(i.e., applications can't tell the difference). One of the nice powers
of XML is that it allows me to distribute my data production and provide
"fused views" of that data. If this issue goes unaddressed by the XLink
committee, it will result in different, non-interoperable,
interpretations of link behaviors.
As an aside, the "show" syntax gives the impression that the XLink group
is limiting their thinking to display characteristics of the data.
Doesn't this mindset limit the usefulness of links for other
Tim Bray wrote:
> And I don't think it's out of place to report in this venue that
> the XLink WG has placed itself on a very short deadline to get its
> long-overdue job done. Watch for a rapid succession of Working Drafts
> converging to a Proposed Recommendation in the immediate future.
Looks like we best push this issue ... fast!
P.S. Where's David Megginson? Haven't seen a posting from him in ages.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)