Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
