Lloyd Rutledge | 2 Oct 2000 14:07
Picon
Picon
Favicon

Re: Conformance value of "+xml"? (was empty, or "[symm]")


On Sat, Sep 30 2000 Chris Lilley wrote:

> Lloyd Rutledge wrote:
> > The reason that the SMIL 2.0 spec does not require that
> > browsers process XPointer is that browsers don't and can't process
> > XPointer -- servers do.  Please correct me if my understanding of the
> > general architecture is too primitive,
> 
> OK. Your understanding is not correct. Servers do not process the fragment
> identifiers, because therse are not sent to the server (queries, following
> a ? character, *are* sent to the server and perhaps that is what you are
> thinking of?)
> 
> > but servers process XPointer,
> > not clients -- right?. 
> 
> No.
> 
> > Clients send URI's to the given server,
> 
> yes. The fragment is not part of the URI and is not sent
> 
> >  the
> > server processes it and returns the located data to the client.
> 
> Yes, and then the client locates the relevant part of this resource using
> the fragment identifier.

Thanks, Chris -- I stand corrected.  Other main points from my
(Continue reading)

Chris Lilley | 2 Oct 2000 16:58
Picon
Favicon

Re: Conformance value of "+xml"? (was empty, or "[symm]")


Lloyd Rutledge wrote:
> 
> On Sat, Sep 30 2000 Chris Lilley wrote:
> > OK. Your understanding is not correct. Servers do not process the fragment
> > identifiers, because therse are not sent to the server (queries, following
> > a ? character, *are* sent to the server and perhaps that is what you are
> > thinking of?)

> Thanks, Chris -- I stand corrected.  Other main points from my
> previous post still stand, though.

Yes, of course. I was not disagreeing with your entire post - just the
particular part about fragment identifiers appended to URIs.

>  Many SMIL constructs have values
> that are XPointer subsets, rather than being SMIL-only.  This
> minimizes format re-learning and facilitates future further
> incorporation of XPointer.  Full XPointer is not required in SMIL, but
> is explicitly enabled.

That seems to be wise at this point; a future direction is clearly shown,
and what is there is compatible (proper subset) so a general purpose
XPointer inmplementation can be used.

--

-- 
Chris

Paul Grosso | 2 Oct 2000 17:15

Re:

At 02:59 2000 09 30 +0200, Chris Lilley wrote:
>"Simon St.Laurent" wrote:
>> At 01:33 AM 9/30/00 +0200, Chris Lilley wrote:
>> >> Used in a query string, XPointers could be processed by the server,
>> >
>> >they could be, but then they wouldn't be fragment identifiers. besides,
>> >thats what the XML Query WG is cooking up, right?
>> 
>> I'm not sure why you feel they wouldn't be fragment identifiers.
>
>I am using the term fragment identifiers in the sense it is used in the
>UROI specifications. 

I found a mention of fragment identifier and the # separator in
RFC 2396 [1], but I'm still looking for the discussion of the ?
and | separator (especially, whether they require/allow the entire
resource to be downloaded first or not and exactly where/by whom 
the bit after the | or ? should get processed).  Can someone give
pointers to the specs that answer these questions?  (I've already
looked at RFC 1738, 1808, and 2396.)  Thanks.

[1] ftp://ftp.ietf.org/rfc/rfc2396.txt

>> I strongly hope that the XML Query WG doesn't feel compelled to reinvent
>> this particular wheel or worse, create a syntax that bars the reuse of
>> XPointers for this work. 
>
>My understanding is that their work builds on XPointer.

You should read the following public documents if you want to know more:
(Continue reading)

Simon St.Laurent | 2 Oct 2000 17:24
Favicon

Re: Conformance value of "+xml"? (was empty, or "[symm]")

At 02:07 PM 10/2/00 +0200, Lloyd Rutledge wrote:
>Having W3C require implementors of one standard be required to
>implement several others from day one, if that correctly paraphrases
>you, Simon, may have its merits -- and with the luxury of not being an
>implementor myself, I'm inclined to see these merits.  However,
>(speaking as advocate-in-proxy) implementors are typically very hard
>pressed to implement even the one standard for the first release,
>especially is that release date is targeted to coincide with the
>release of the format itself.  This is complicated further if the
>related standard itself is not yet released as a recommendation, as is
>the case with XPointer.  If every potentially related standard had to
>also be implemented, it would be a long time before we see SMIL 2.0,
>and other formats, first emerge in any practical sense.  It may be
>wise to slow release cycles as part of deliberate full step-by-step
>inter-format integration, but it would put a hard-to-ignore strain on
>implementors.

I agree that it puts strain on implementors, but I think it points to an
architectural implementation change that XML is driving: moving toward
reusable code at various levels of a program.

At some point I'd like to dream that this will be an integration problem
rather than a development problem, but right now I can see where that's not
too promising.  Getting generic modules out into the world and used is
pretty difficult, it seems.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books
(Continue reading)

Eve L. Maler | 2 Oct 2000 17:36
Picon

Re:

At 10:15 AM 10/2/00 -0500, Paul Grosso wrote:
>I found a mention of fragment identifier and the # separator in
>RFC 2396 [1], but I'm still looking for the discussion of the ?
>and | separator (especially, whether they require/allow the entire
>resource to be downloaded first or not and exactly where/by whom
>the bit after the | or ? should get processed).  Can someone give
>pointers to the specs that answer these questions?  (I've already
>looked at RFC 1738, 1808, and 2396.)  Thanks.
>
>[1] ftp://ftp.ietf.org/rfc/rfc2396.txt

The "query component" (starting with a ?) is discussed in RFC 2396, but I'm 
surprised, on reading this now, that it doesn't say more about the 
server/user agent distinction.  It does say "The query component is a 
string of information to be interpreted by the resource", and perhaps 
that's 2396-speak meaning that it's information to be interpreted by the 
system that serves the resource.

The | separator was invented out of whole cloth in an early version of 
XLL/XLink; when we (the W3C XML Linking WG) broke out the XPointer stuff 
into its own spec, the | went away because we had been inappropriately 
messing with basic URI functionality.  Once we got on the track of defining 
a fragment identifier language for a particular set of media types, the 
scope became somewhat simpler and clearer.

         Eve
--
Eve Maler                                          +1 781 442 3190
Sun Microsystems XML Technology Center    eve.maler  <at>  east.sun.com

(Continue reading)

Simon St.Laurent | 2 Oct 2000 20:21
Favicon

MIME-XML technology?

Does anyone know what the "MIME-XML technology to wrap and send the
message" this article discusses might be?

http://www.sdtimes.com/news/015/story1.htm

It sounds at the end like there's some Sun messaging spec (JAXN) involved,
but I'm pretty irritated to find 'MIME-XML technology' set up in some kind
of weird contrast to SOAP.

I don't love SOAP, and I doubt the journalist was given great information
about this 'MIME-XML' critter, but I'm really scratching my head.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books

Philipp Hoschka | 2 Oct 2000 20:22
Picon
Favicon

Re: MIME-XML technology?

They're referring to multipart-MIME - that's what ebXML is using to
assemble different documents (of any format) into one message.

The ebXML TRP spec is online, btw - check out the ebXML website
(locatable via google search).

This discussion is probably more appropriate for the xml-dist-app
list.

"Simon St.Laurent" a écrit :
> 
> Does anyone know what the "MIME-XML technology to wrap and send the
> message" this article discusses might be?
> 
> http://www.sdtimes.com/news/015/story1.htm
> 
> It sounds at the end like there's some Sun messaging spec (JAXN) involved,
> but I'm pretty irritated to find 'MIME-XML technology' set up in some kind
> of weird contrast to SOAP.
> 
> I don't love SOAP, and I doubt the journalist was given great information
> about this 'MIME-XML' critter, but I'm really scratching my head.
> 
> Simon St.Laurent
> XML Elements of Style / XML: A Primer, 2nd Ed.
> XHTML: Migrating Toward XML
> http://www.simonstl.com - XML essays and books

Simon St.Laurent | 2 Oct 2000 20:31
Favicon

Re: MIME-XML technology?

At 08:22 PM 10/2/00 +0200, Philipp Hoschka wrote:
>They're referring to multipart-MIME - that's what ebXML is using to
>assemble different documents (of any format) into one message.
>
>The ebXML TRP spec is online, btw - check out the ebXML website
>(locatable via google search).
>
>This discussion is probably more appropriate for the xml-dist-app
>list.

Agreed - I was just irritated by the naming convention used in the article,
which suggests that something more is going on between MIME and XML.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books

Eve L. Maler | 2 Oct 2000 21:52
Picon

Re: MIME-XML technology?

At 08:22 PM 10/2/00 +0200, Philipp Hoschka wrote:
>They're referring to multipart-MIME - that's what ebXML is using to
>assemble different documents (of any format) into one message.
>
>The ebXML TRP spec is online, btw - check out the ebXML website
>(locatable via google search).
>
>This discussion is probably more appropriate for the xml-dist-app
>list.

Just to round things off, the relevant spec is at:

   http://www.ebxml.org/specdrafts/ebXML_Messaging_Service_Specification_v0-21.pdf

         Eve
--
Eve Maler                                          +1 781 442 3190
Sun Microsystems XML Technology Center    eve.maler  <at>  east.sun.com

Mark Baker | 13 Oct 2000 19:52
Picon

Requiring charset parameter on +xml types?

Greetings,

At the HTML WG f2f yesterday, it was proposed that we should require the
use of the charset parameter on the XHTML media type.  This came up in
the discussion over whether the media type should use application/ or
text/.

Would requiring this parameter help solve the problem of those broken
web servers that I've heard about that mislabel non-US-ASCII encoded
text/* content as US-ASCII?

Are the any other issues/pros/cons we should be aware of for requiring
this parameter?

Thanks.

BTW, for W3C members that are interested (i.e. it's not required reading
to grok this message - mustUnderstand = 0 :-), the IRC log of the
conversation is available at;

http://lists.w3.org/Archives/Member/w3c-html-wg/2000OctDec/0104.html

MB


Gmane