XML MULTI-Fragment Interchange?

[Paul Grosso]

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 
on xml-dev.  

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.

paul

Paul Grosso
Chair, XML Fragment WG

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)