RE: AFTF requirements list with comments, pre-2003/01/28 telcon (revised)

>>  I would like to allow frag ids, specifically 
>> so that parts could actually be fragments within an
>> xml document.  One example would be a soap with 
>> attachments package that contains 2 xml documents, 
>> and the first refers to a part that is within the
>> 2nd xml document. 

Hmm.  This is an interesting idea, and I can see the merits.  On the other 
hand, don't we then lose the ability for the parts themselves to have a 
MIME type and for fragments to reference within the parts?  I wonder 
whether that isn't the more important use case.  I'm nervous about trying 
to allow both at the same time.  Does the web even allow:  xxxx#a#b  to 
reference a piece of a part that is itself within an XML document? 

I think the design point for parts is only secondarily XML within XML, I 
think it's primarily non-XML data, and I think MIME types are the obvious 
web-compatible way to handle that.   I think it's important that 
attachments are just web resource (or at least representations of web 
resources) that happen to travel with the messages.  I'm not sure your 
proposal is compatible with that view.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"David Orchard" <dorchard@bea.com>
01/30/2003 05:48 PM

 
        To:     <noah_mendelsohn@us.ibm.com>
        cc:     <xml-dist-app@w3.org>
        Subject:        RE: AFTF requirements list with comments, pre-2003/01/28 telcon (revised)


Web architecture doesn't stipulate absolute URIs.  I would like to allow
frag ids, specifically so that parts could actually be fragments within an
xml document.  One example would be a soap with attachments package that
contains 2 xml documents, and the first refers to a part that is within 
the
2nd xml document.  I expect that in most cases, people would use absolute
URIs, but I can think of scenarios where they would want a fragment. Let's
make this a bit more concrete.  I want to chunk a large xml document.  Say 
I
decide to split this into 2 documents. I could use an xinclude in the 
first
to refer to the 2nd, and I have an application that reads the first chunk,
then afterwards resolves the xinclude.  As XML requires a root note, the
XInclude has to point to a fragment in the 2nd document, specifically all
the children of the root node.

Now if a new version of XML allowed xml to not have a root node, like
external entities, this might be solved. :-)

I absolutely agree with carrying the media type.  Violently in fact. These
documents, and parts, must be correctly self-describing.  Now that's web
architecture!

Cheers,
Dave

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Thursday, January 30, 2003 2:13 PM
> To: David Orchard
> Cc: xml-dist-app@w3.org
> Subject: RE: AFTF requirements list with comments,
> pre-2003/01/28 telcon
> (revised)
>
>
> I stand corrected.  You're right of course.  Still, I would
> think that we
> want to follow web architecture.  As far as I know, that
> means that the
> resource which is a part should be identified by an absolute URI (not
> relative, NO fragment ID.)  References to the part as a whole
> should allow
> relative and absolute forms.  References within parts that have known
> media type should allow URI References, including fragment ID.
>
> Bottom line:  a part is named by an absolute URI.  References
> are in the
> form of URI references, but Fragid is a reference within the part.
> Specifically, two references that differ only in their fragid
> must resolve
> to the same part.
>
> Also:  on the phone call I suggested a requirement that the
> attachment
> implementation be capable of carrying a media type for each part.
>
> David:  does this sound right?
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>
>
>
>
> "David Orchard" <dorchard@bea.com>
> 01/30/2003 05:02 PM
>
>
>         To:     <noah_mendelsohn@us.ibm.com>
>         cc:     <xml-dist-app@w3.org>
>         Subject:        RE: AFTF requirements list with
> comments, pre-2003/01/28 telcon (revised)
>
>
> ../a has nothing to do with URI References vs URIs.  ../a is
> allowed by
> URIs
> and by URI references.  You might be thinking of absolute
> URIs however :-)
>
> URI References are URIs that may have fragments.  Oh darn, we
> don't have a
> term for a URI that has an absolutized portion that may have
> fragments.
>
> Cheers,
> Dave
>
> > -----Original Message-----
> > From: xml-dist-app-request@w3.org
> > [mailto:xml-dist-app-request@w3.org]On
> > Behalf Of noah_mendelsohn@us.ibm.com
> > Sent: Thursday, January 30, 2003 1:43 PM
> > To: David Orchard
> > Cc: xml-dist-app@w3.org
> > Subject: RE: AFTF requirements list with comments,
> > pre-2003/01/28 telcon
> > (revised)
> >
> >
> >
> > David Orchard suggests:
> >
> > >> DR6. The specification must permit parts to be identified
> > by URIs or URI
> > References.  This is similar to ChrisF's comment.
> >
> > I am a little surprised.  I would have thought that what we want is:
> >
> > * The identity of each part is a URI (I.e. an absolute URI)(
> >
> > * References to parts are in the form of URI references (which are
> > resolved through the usual mechanisms to yield the absolute URI).
> >
> > David:  are you really saying that you want to allow "../a" as the
> > identity of a part?  Thanks.
> >
> > ------------------------------------------------------------------
> > Noah Mendelsohn                              Voice: 1-617-693-4036
> > IBM Corporation                                Fax: 1-617-693-8676
> > One Rogers Street
> > Cambridge, MA 02142
> > ------------------------------------------------------------------
> >
> >
> >
>
>
>
>
>

Received on Thursday, 30 January 2003 19:33:02 UTC