W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > April 2006

Re: URIs as inputs and outputs

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Fri, 07 Apr 2006 17:17:36 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87odzd13wv.fsf@nwalsh.com>
/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
|> I don't see an obvious way for one component to generate an arbitrary
|> series of URIs that another component can consume.
| Ah. I was assuming that whenever a component generated documents with URIs
| that weren't known at design time, it would create some kind of index document
| that listed the URIs for the various documents that were generated.

We could do that. While it has advantages, it seems to impose a fair
amount of burden on the processors. (Can you do a totally streaming
pipeline this way? I'm not sure.)

| <book>
|   <chapters>
|     <chapter href="ch01.xml" />
|     <chapter href="ch02.xml" />
|     ...
|   </chapters>
|   <graphics>
|     <graphic href="fg01.svg" />
|     <graphic href="fg02.svg" />
|     ...
|   </graphics>
| </book>

Hmm. This suggests that the format of the manifest would be up to the
component. I think if we had a manifest, we'd have to standardize it.

| (Actually I think in most cases the 'index document' would be a natural
| by-product of the component.)

That's certainly true.

| I'm not totally enamoured of this -- it's hard to support URIs that aren't
| known at design time without some kind of URI-manipulation support. But URI
| support is always going to be an issue because of wanting to do
| cross-references between documents...


                                        Be seeing you,

Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

Received on Friday, 7 April 2006 21:17:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:39 UTC