Lists Home |
Date Index |
- From: Paul Grosso <firstname.lastname@example.org>
- To: <email@example.com>
- Date: Thu, 04 Mar 1999 17:26:07 -0600
At 14:06 1999 03 04 -0800, Don Park wrote:
>The first draft of the XML Fragment spec allows only one Fragbody. Could
>someone from the WG shed some light on why this constraint is important?
First, let me remind folks that only comments sent to the archived
mail list set up for comments are "officially" considered. The WG
cannot promise to honor all requests for responses to questions posted
However, the answer to Don's question will probably address a lot of
other questions, and the WG did consider it carefully, so I would like
to answer that here.
One of the key principals in developing this version of the Fragment
Interchange spec was to define and remain within a limited scope. The
problem was (1) to define what fragment context information is, (2) to
define a fragment context specification notation, and (3) to define at
least one interoperable method for associating a fragment context
specification with a fragment body.
Although we did decide to address point (3) by defining a simple
"packaging" scheme, we were very careful to do the minimum necessary
to address point (3). Specifically, we did not want to enlarge our scope
to include packaging methods in general. It is expected that the XML
Activity of the W3C will consider ways to address packaging in the near
future, and the XML Fragment WG didn't want to do something that might
later constrain a more general solution. Packaging multiple entities
in a single unit is likely to be a useful thing to do in general of which
packaging multiple fragment bodies is just one example. The WG didn't
want to define a way to address multiple fragment bodies and then discover,
when the more general problem is carefully considered, that our solution
wasn't a subset of the solution to the more general problem.
In summary, the WG is aware of lots of improvements, enhancements, and
extensions that could be made to an XML Fragment Interchange spec, but
we ruthlessly kept ourselves to the "minimum needed to declare victory."
We expect work on Schemas and Packaging and XLink and probably other
areas will all contribute technology that would be useful in a version 2
XML Fragment Interchange spec someday, but we believe that implementation
and user experience should prove the version 1 spec useful before we even
think about a version 2.
Of course, if you seriously believe that the spec is useless unless it
allows multiple fragment bodies per package, then that is a comment you
should make and attempt to support. We don't want to come out with a
spec folks think is useless, but we were trying to keep it as minimal
as possible while still addressing the problem we defined as our scope.
Chair, XML Fragment WG
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)