Subject: Re: Conformance value of "+xml"?
From: [email-masked]
To: [email-masked]
Date: Sat, 30 Sep 2000 13:22:06 +0900 (JST)
List-Id: <ietf-xml-mime.imc.org>

I am happy to to see discussion about XPointer and media types, and
encourage it.  Nevertheless, I believe that there are no problems in
promoting the latest I-D to an RFC.

Since XPointer is not a W3C recommendation but rather a candidate
recommendation, the latest I-D merely mentions it and does NOT
reference it in a normative manner.  

After publication of a proposed standard, XPointer and SVG will
probably be promoted to W3C recommendations.  I hope to incorporate
necessary changes when we publish another RFC for XML media types.

Cheers,

IBM Tokyo Research Lab &
International University of Japan, Research Institute

MURATA Makoto

Date: Sat, 30 Sep 2000 02:59:20 +0200
From: Chris Lilley <[email-masked]>
Organization: W3C
To: "Simon St.Laurent" <[email-masked]>
CC: Lloyd Rutledge <[email-masked]>, [email-masked], [email-masked]
Subject: Re: 
Sender: [email-masked]

"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,
> >that s 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. If you mean some other, more general usage then that
might be correct depending on your definition.

> 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.

-- 
Chris

Date: Fri, 29 Sep 2000 20:51:19 -0400
To: Chris Lilley <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: 
Cc: Lloyd Rutledge <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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,
>that s what the XML Query WG is cooking up, right?

I'm not sure why you feel they wouldn't be fragment identifiers.

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.  I'd hate to have to learn two different sets of
rules for identifying parts of documents...

>> >Yes, and then the client locates the relevant part of this resource using
>> >the fragment identifier.
>> 
>> In some cases, that's great, but in others it's a giant waste of network
>> resources.
>
>Which is why we have both ? and #

Yep.  And let's try to let the two options work together, rather than as
totally different universes.

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

Date: Sat, 30 Sep 2000 01:33:45 +0200
From: Chris Lilley <[email-masked]>
Organization: W3C
To: "Simon St.Laurent" <[email-masked]>
CC: Lloyd Rutledge <[email-masked]>, [email-masked], [email-masked]
Subject: Re: 
Sender: [email-masked]

"Simon St.Laurent" wrote:
> 
> At 12:38 AM 9/30/00 +0200, Chris Lilley wrote:
> >> but servers process XPointer,
> >> not clients -- right?.
> >
> >No.
> 
> Used in a query string, XPointers could be processed by the server,

they could be, but then they wouldn't be fragment identifiers. besides,
that s what the XML Query WG is cooking up, right?

> resulting in much less network overhead.  It's a cheap form of querying,
> but there do seem to be a lot of people interested in such activity.

I agree lots of people are interested. Nothing against queries.

> >Yes, and then the client locates the relevant part of this resource using
> >the fragment identifier.
> 
> In some cases, that's great, but in others it's a giant waste of network
> resources.

Which is why we have both ? and #

--
Chris

Date: Fri, 29 Sep 2000 18:44:24 -0400
To: Chris Lilley <[email-masked]>, Lloyd Rutledge <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 12:38 AM 9/30/00 +0200, Chris Lilley wrote:
>> but servers process XPointer,
>> not clients -- right?. 
>
>No.

Used in a query string, XPointers could be processed by the server,
resulting in much less network overhead.  It's a cheap form of querying,
but there do seem to be a lot of people interested in such activity.

>>  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.

In some cases, that's great, but in others it's a giant waste of network
resources.

Good for the networking companies, though!

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

Date: Sat, 30 Sep 2000 00:38:36 +0200
From: Chris Lilley <[email-masked]>
Organization: W3C
To: Lloyd Rutledge <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: 
Sender: [email-masked]

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.

--
Chris

To: [email-masked], [email-masked]
cc: [email-masked]
Date: Wed, 27 Sep 2000 17:16:21 +0200
From: Lloyd Rutledge <[email-masked]>
Sender: [email-masked]

At Tue, 26 Sep 2000 11:29:50 -0400, Simon St.Laurent wrote [1]
> At 09:59 AM 9/26/00 -0400, Mark Baker wrote:
> >My understanding from Dan was that the cat's already out of the bag; SVG
> >uses +xml.
> 
> On fragment identifiers, SVG, SMIL, and XHTML all have potential problems.
> 
> I'm even more concerned that there are a lot of XML applications out there
> which haven't considered the problem at all - it's not something that comes
> up as a question in XML tutorials that I've seen.  (I'll be adding it to
> future editions, believe me.)
> 
> On the other hand, I'm not sure that the problem is quite as drastic as it
> seems.  Any XML application can point into an SVG, SMIL, or XHTML document
> using XPointer.  It's just that SVG, SMIL, and XHTML applications may not
> let those documents point _out_ using XPointer.
> 
> While I'd like to say across the board that EVERYONE should use XPointer in
> all its glory when they use XML, it's awfully hard to push that when the
> W3C hasn't made that case across the board.
> 
> It's hard to push it while we still have language like this [1]:
> 
> >XPointer [XPTR] allows components of XML documents to be addressed 
> >in terms of their placement in the XML structure rather than on 
> >their unique identifiers. This allows referencing of any portion 
> >of an XML document without having to modify that document. Without 
> >XPointer, pointing within a document may require adding unique 
> >identifiers to it, or inserting specific elements into the document, 
> >such as a named anchor in HTML. XPointers are put within the fragment 
> >identifier part of a URI [URI]. The SMIL 2.0 specification does not 
> >require that browsers be able to process XPointers in SMIL 2.0 URI 
> >attributes. 
> 
> [1] -
> http://www.w3.org/TR/smil20/extended-linking.html#SMILLinking-Relationship-t
> o-XPointer
> 
> Simon St.Laurent
> XML Elements of Style / XML: A Primer, 2nd Ed.
> XHTML: Migrating Toward XML
> http://www.simonstl.com - XML essays and books

The above text from the SMIL spec is not meant to demean XPointer, it
is there to discourage misconceptions about its potential relation
with SMIL.  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, but servers process XPointer,
not clients -- right?.  Clients send URI's to the given server, the
server processes it and returns the located data to the client.  Since
browsers are clients, they don't process XPointer, they just package
up much of the URI string and send it out, and wait for the response.

Keep in mind that SMIL does not require the use of any format other
than SMIL, even though it is completely dependent on other formats.
SMIL is an integration language: it contains locations of media
objects and descriptions of how these are combined to make a
multimedia presentation.  The formats of these media objects is not
specified for SMIL.  Authors in SMIL choose formats for their
integrated media that they can determine receives substantial support
in SMIL browsers.  It's a free-market integration format, and that's
the best way to go about it.

Similarly, authors will also choose locations format like XPointer in
SMIL if there there are servers that process it and return useful
media data.  Authors are completely able to use XPointer in SMIL
presentations, and nothing in the current spec inhibits this.  Some
SMIL attributes take URI's, primarily to locate media, and URI's these
days can contain XPointer.  The ability of browsers to process
presentations with XPointer depends not on their processing XPointer,
since that's done by servers, but their ability to process the media
these servers return and to integrate it into the presentation.
Authors will choose to use XPointer in SMIL presentations if there are
XPointer servers at the URI's giving media they need, and if the SMIL
browsers can processes the non-XPointer media data that is returned.

I believe what's written above applies to HTML, and perhaps to SVG as
well.

Nonetheless, XPointer is certainly a specified and required part of
SMIL.  SMIL uses XPointer values in certain attributes for internal
SMIL-to-SMIL communication, such as specifying endpoints of links and
synchronization relationships.

-Lloyd

[1] http://www.imc.org/ietf-xml-mime/mail-archive/msg00583.html

--
Lloyd Rutledge  vox: +31 20 592 41 27       fax: +31 20 592 41 99
CWI             net: [email-masked]  Web: http://www.cwi.nl/~lloyd
Post:   PO Box 94079   |  NL-1090 GB Amsterdam  |  The Netherlands
Street: Kruislaan 413  |  NL-1098 SJ Amsterdam  |  The Netherlands

Date: Wed, 27 Sep 2000 10:44:15 -0400
From: Mark Baker <[email-masked]>
Organization: Sun Microsystems Inc.
To: [email-masked]
Subject: Re: Conformance value of "+xml"?
Sender: [email-masked]

Tim Bray wrote:
> Right.  I think that the +xml idiom is useful even if it doesn't guarantee
> that such documents are going use XLink/XPointer for outgoing links.

Right.

I hadn't considered outgoing links, but I don't believe them relevant to
this discussion.  Only the processor of the document that is referenced
should care.

> Hmm, it also seems that anything that's of type *+xml has, per definition,
> internal structures which can be addressed by xpointer whether the
> media-type designers foresaw that or not. -Tim

Well, you're right if you're talking about doing this all by hand,
outside the context of an architecture, i.e. if you just pass (however
you want to do it) an SVG document to an XML processor that supports
XPointer, then you can address that SVG with XPointer.  No problem.

The issue is, in the context of MIME dispatch, what can the *dispatched*
processor be guaranteed to interpret for us.

>From RFC 2396, 4.1;

   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.  Therefore, the format and interpretation of
   fragment identifiers is dependent on the media type [RFC2046] of the
   retrieval result.

Which means that if a processor is dispatched to handle a particular
media type, then it is the registration of that media type that defines
the normative syntax to be used to reference its internal structure via
that processor.  In other words, there's no guarantee that the processor
can interpret XPointer fragment identifiers.

If you want to use the knowledge that the media type ends with "+xml" to
dispatch to a {text|application}/xml processor instead, then that will
give you XPointer (though draft-murata-xml references it
non-normatively, due to the scheduling problem I assume).  But a content
author is now SOL in terms of being able to guarantee that there's any
further dispatch to the SVG processor (see draft-murata-xml section 3,
last paragraph), so the image may not get displayed.

MB

Date: Wed, 27 Sep 2000 11:22:04 +0900
To: "Eve L. Maler" <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: XPointer scheme names (was Re: Conformance value of "+xml"?)
Cc: Chris Lilley <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked], Mark Baker <[email-masked]>, [email-masked]
Sender: [email-masked]

At 00/09/26 10:50 -0400, Eve L. Maler wrote:
>At 02:40 PM 9/26/00 +0900, Martin J. Duerst wrote:

>>XPointer, at http://www.w3.org/TR/xptr#schemes, says how
>>such extensions can happen. I think the RFC should make sure
>>that it references that part or is otherwise in sync with it.
>>
>>So what I would like to see here is some text that says that
>>any registrations must use a subset of the XPointer syntax.
>>
>>For new applications, that means that if they need an xpointer
>>scheme not currently in the xpointer TR, they have to make sure
>>it gets registered by getting added to the XPointer errata document.
>
>I like the idea of defining subsets of XPointer for the fragment 
>identifiers into their XML-based languages.  However, I'm not crazy about 
>having to modify XPointer through errata every time.  We were required to 
>remove the "arbitrary scheme" functionality in XPointer in order to avoid 
>a situation where designers choose conflicting scheme names; the note 
>about "errata" that's in there now is just because we weren't sure how we 
>were going to get out of this mess, and we wanted to keep people informed.

Okay, so the XPointer errata are a hook to whatever may happen
in the future, rather than the actual location of a registry.
I think that makes sense.

>Murata Makoto has since pointed out to me that we simply need to rely on 
>the system of IETF media type registration documents to avoid this.

I think that works very well is a given media type wants to define
a subset of the xpointer scheme, for example.

>In this manner, SVG could perhaps define its fragment identifier language 
>to be a "subset" of XPointer that consists of an svg(...) scheme plus a 
>few things from the xpointer(...) scheme.  No one else could choose "svg" 
>as a scheme name and get away with it.

I'm not sure that the IETF media type registry is very efficient for this.
If somebody has a new idea for an XPointer scheme foo(), they would have
to search through all registered types (not only the +xml types, because
as far as I understand, there is no MUST to register an xml type with
+xml). That's really a lot.

On the other hand, I think that the list of XPointer schemes should be
kept very small, and that it will stay very small. For example, SVG
doesn't define an svg() scheme. The most obvious candidates are
for temporal and spacial identification for audio, video, and graphics.
Because of this small number, I think it would be very good to actually
maintain a list of pointers (e.g. in the XPoiter errata or in a
document pointed to from there), whereas the actual definition of
a new scheme could be in the IETF media types registry or in the
spec of a document type referenced from there.

>>The registration should then document which part of XPointer it
>>supports.
>>
>>For interoperability, this means that any +xml type will support
>>a subset of XPointer as a fragment identifier. Some may only support
>>the bare #<identifier> syntax, some may add #xpointer(id(<identifier>))
>>as SVG did, some may support the full xpointer scheme, some may
>>support some other scheme (e.g. a temporal scheme for audio or video,...).
>>The interoperability guarantee that this gives is that it is not possible
>>to construct a fragment identifier that means one thing for one type
>>and another thing for another type. Either it means something for
>>a given type, or it's not understood for that given type.
>>
>>I'm not sure I'm happy with this; defining a minimum that every
>>+xml type has to support would be very desirable in my eyes.
>>That's one of the ideas behind the +xml suffix, isn't it.
>>So how should this minimum look like?
>
>Does a document such as draft-murata-xml-0[78] have the "right" to define 
>such a minimum?  If so, I'd be very interested to hear what people think 
>it should contain.

It defines the +xml convention, and therefore can say what a document
type has to do to fit this convention.

Regards,   Martin.

Date: Tue, 26 Sep 2000 11:30:53 -0700
To: "Simon St.Laurent" <[email-masked]>, [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: Conformance value of "+xml"?
Sender: [email-masked]

At 11:29 AM 26/09/00 -0400, Simon St.Laurent wrote:
>At 09:59 AM 9/26/00 -0400, Mark Baker wrote:
>>My understanding from Dan was that the cat's already out of the bag; SVG
>>uses +xml.

Not quite yet, but as Chris says, probably will.

>On the other hand, I'm not sure that the problem is quite as drastic as it
>seems.  Any XML application can point into an SVG, SMIL, or XHTML document
>using XPointer.  It's just that SVG, SMIL, and XHTML applications may not
>let those documents point _out_ using XPointer.

Right.  I think that the +xml idiom is useful even if it doesn't guarantee
that such documents are going use XLink/XPointer for outgoing links.  

Hmm, it also seems that anything that's of type *+xml has, per definition,
internal structures which can be addressed by xpointer whether the 
media-type designers foresaw that or not. -Tim

Date: Tue, 26 Sep 2000 10:50:07 -0400
To: "Martin J. Duerst" <[email-masked]>
From: "Eve L. Maler" <[email-masked]>
Subject: XPointer scheme names (was Re: Conformance value of "+xml"?)
Cc: Chris Lilley <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked], Mark Baker <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:40 PM 9/26/00 +0900, Martin J. Duerst wrote:
>At 00/09/25 17:04 +0200, Chris Lilley wrote:
>> > For the fifth paragraph I'd recommend changing the wording to reflect
>> > that for fragment identifiers at least, registrations are free to
>> > *extend* the syntax, but must at least support the XML syntax;
>>
>>In the case of SVG, since there seemed to be little prior experience with
>>the full complexities of XPoinbter, SVG supports a subset of the syntax. So
>>the uses in an  SVG instance will all conform to the XPointer spec, but the
>>converse is not true - not all valid XPointers are guaranteed to be
>>processd by SVG-aware user agents.
>
>XPointer, at http://www.w3.org/TR/xptr#schemes, says how
>such extensions can happen. I think the RFC should make sure
>that it references that part or is otherwise in sync with it.
>
>So what I would like to see here is some text that says that
>any registrations must use a subset of the XPointer syntax.
>
>For new applications, that means that if they need an xpointer
>scheme not currently in the xpointer TR, they have to make sure
>it gets registered by getting added to the XPointer errata document.

I like the idea of defining subsets of XPointer for the fragment 
identifiers into their XML-based languages.  However, I'm not crazy about 
having to modify XPointer through errata every time.  We were required to 
remove the "arbitrary scheme" functionality in XPointer in order to avoid a 
situation where designers choose conflicting scheme names; the note about 
"errata" that's in there now is just because we weren't sure how we were 
going to get out of this mess, and we wanted to keep people informed.

Murata Makoto has since pointed out to me that we simply need to rely on 
the system of IETF media type registration documents to avoid this.  In 
this manner, SVG could perhaps define its fragment identifier language to 
be a "subset" of XPointer that consists of an svg(...) scheme plus a few 
things from the xpointer(...) scheme.  No one else could choose "svg" as a 
scheme name and get away with it.

Does this make sense to all you experts?

>The registration should then document which part of XPointer it
>supports.
>
>For interoperability, this means that any +xml type will support
>a subset of XPointer as a fragment identifier. Some may only support
>the bare #<identifier> syntax, some may add #xpointer(id(<identifier>))
>as SVG did, some may support the full xpointer scheme, some may
>support some other scheme (e.g. a temporal scheme for audio or video,...).
>The interoperability guarantee that this gives is that it is not possible
>to construct a fragment identifier that means one thing for one type
>and another thing for another type. Either it means something for
>a given type, or it's not understood for that given type.
>
>I'm not sure I'm happy with this; defining a minimum that every
>+xml type has to support would be very desirable in my eyes.
>That's one of the ideas behind the +xml suffix, isn't it.
>So how should this minimum look like?

Does a document such as draft-murata-xml-0[78] have the "right" to define 
such a minimum?  If so, I'd be very interested to hear what people think it 
should contain.

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

Date: Tue, 26 Sep 2000 13:19:18 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Conformance value of "+xml"?
Sender: [email-masked]

At 05:58 PM 9/26/00 +0200, Chris Lilley wrote:
>"Simon St.Laurent" wrote:
>> On fragment identifiers, SVG, SMIL, and XHTML all have potential problems.
>
>Such as?

Just this, which came a bit further down.

>> Any XML application can point into an SVG, SMIL, or XHTML document
>> using XPointer.  It's just that SVG, SMIL, and XHTML applications may not
>> let those documents point _out_ using XPointer.

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

Date: Tue, 26 Sep 2000 17:58:26 +0200
From: Chris Lilley <[email-masked]>
Organization: W3C
To: "Simon St.Laurent" <[email-masked]>
CC: [email-masked]
Subject: Re: Conformance value of "+xml"?
Sender: [email-masked]

"Simon St.Laurent" wrote:
> 
> At 09:59 AM 9/26/00 -0400, Mark Baker wrote:
> >My understanding from Dan was that the cat's already out of the bag; SVG
> >uses +xml.

Actually we currently use -xml which was what an earlier version of the
internet draft said, and will consider switching to whatever the eventual
internet standard says once it settles down.

> On fragment identifiers, SVG, SMIL, and XHTML all have potential problems.

Such as?

> I'm even more concerned that there are a lot of XML applications out there
> which haven't considered the problem at all - it's not something that comes
> up as a question in XML tutorials that I've seen.  (I'll be adding it to
> future editions, believe me.)
> 
> On the other hand, I'm not sure that the problem is quite as drastic as it
> seems.  Any XML application can point into an SVG, SMIL, or XHTML document
> using XPointer.  It's just that SVG, SMIL, and XHTML applications may not
> let those documents point _out_ using XPointer.
> 
> While I'd like to say across the board that EVERYONE should use XPointer in
> all its glory when they use XML, it's awfully hard to push that when the
> W3C hasn't made that case across the board.

Yes, I share the concern. That is why SVG 1.0 uses #xptr(id(foo)) when this
gives no more functionality than good old #foo - it indicates future
direction, and I would expect versions of SVG greater than 1.0 to use the
ful xpointer syntax. 

The WG didn't want to bite off fully general pointers, but didn't want to
indicate that XPointer was not to be used, either.

--
Chris

Date: Tue, 26 Sep 2000 11:29:50 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Conformance value of "+xml"?
Sender: [email-masked]

At 09:59 AM 9/26/00 -0400, Mark Baker wrote:
>My understanding from Dan was that the cat's already out of the bag; SVG
>uses +xml.

On fragment identifiers, SVG, SMIL, and XHTML all have potential problems.

I'm even more concerned that there are a lot of XML applications out there
which haven't considered the problem at all - it's not something that comes
up as a question in XML tutorials that I've seen.  (I'll be adding it to
future editions, believe me.)

On the other hand, I'm not sure that the problem is quite as drastic as it
seems.  Any XML application can point into an SVG, SMIL, or XHTML document
using XPointer.  It's just that SVG, SMIL, and XHTML applications may not
let those documents point _out_ using XPointer.

While I'd like to say across the board that EVERYONE should use XPointer in
all its glory when they use XML, it's awfully hard to push that when the
W3C hasn't made that case across the board.

It's hard to push it while we still have language like this [1]:

>XPointer [XPTR] allows components of XML documents to be addressed 
>in terms of their placement in the XML structure rather than on 
>their unique identifiers. This allows referencing of any portion 
>of an XML document without having to modify that document. Without 
>XPointer, pointing within a document may require adding unique 
>identifiers to it, or inserting specific elements into the document, 
>such as a named anchor in HTML. XPointers are put within the fragment 
>identifier part of a URI [URI]. The SMIL 2.0 specification does not 
>require that browsers be able to process XPointers in SMIL 2.0 URI 
>attributes. 

[1] -
http://www.w3.org/TR/smil20/extended-linking.html#SMILLinking-Relationship-t
o-XPointer

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

Date: Tue, 26 Sep 2000 09:59:27 -0400
From: Mark Baker <[email-masked]>
Organization: Sun Microsystems Inc.
To: [email-masked]
Subject: Re: Conformance value of "+xml"?
Sender: [email-masked]

"Martin J. Duerst" wrote:
> I'm not sure I'm happy with this; defining a minimum that every
> +xml type has to support would be very desirable in my eyes.
> That's one of the ideas behind the +xml suffix, isn't it.
> So how should this minimum look like?

My understanding from Dan was that the cat's already out of the bag; SVG
uses +xml.

However, SVG isn't yet a W3C recommendation.  According to
http://www.w3.org/TR/SVG, SVG 1.0 is in CR as of August 2nd.  This CR
references a version of draft-murata-xml that used the "-xml" suffix, so
that's what's used;

http://www.w3.org/TR/SVG/intro.html#MIMEType

Also, IANA shows that a MIME media type for SVG has not yet been
registered.  I think this means we have an opportunity to guarantee
*something* about fragment identifiers.

Here's some options I've come up with.  Each of them has drawbacks, but
hopefully those involved with SVG can weigh that against the future cost
of not having a consistent fragment identifier notation on +xml media
types.

1. leave the SVG MIME media type as-is with "-xml" so it user agents
don't expect the rules of "+xml" to hold.  I don't believe that this is
a great loss for SVG because it's an image/ type, not text/ or
application/ about which encoding rules are defined.  Or just change it
to image/svg.
2. remove that section (1.2) from the spec (as we did with XHTML 1.0, so
we could add it later).
3. break out and document your subset of XPointer so that
draft-murata-xml can reference it

Any other options?  Chris?

MB

Date: Tue, 26 Sep 2000 14:40:29 +0900
To: Chris Lilley <[email-masked]>, Dan Kohn <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: Conformance value of "+xml"?
Cc: [email-masked], Mark Baker <[email-masked]>
Sender: [email-masked]

At 00/09/25 17:04 +0200, Chris Lilley wrote:
> > For the fifth paragraph I'd recommend changing the wording to reflect
> > that for fragment identifiers at least, registrations are free to
> > *extend* the syntax, but must at least support the XML syntax;
>
>In the case of SVG, since there seemed to be little prior experience with
>the full complexities of XPoinbter, SVG supports a subset of the syntax. So
>the uses in an  SVG instance will all conform to the XPointer spec, but the
>converse is not true - not all valid XPointers are guaranteed to be
>processd by SVG-aware user agents.

XPointer, at http://www.w3.org/TR/xptr#schemes, says how
such extensions can happen. I think the RFC should make sure
that it references that part or is otherwise in sync with it.

So what I would like to see here is some text that says that
any registrations must use a subset of the XPointer syntax.

For new applications, that means that if they need an xpointer
scheme not currently in the xpointer TR, they have to make sure
it gets registered by getting added to the XPointer errata document.

The registration should then document which part of XPointer it
supports.

For interoperability, this means that any +xml type will support
a subset of XPointer as a fragment identifier. Some may only support
the bare #<identifier> syntax, some may add #xpointer(id(<identifier>))
as SVG did, some may support the full xpointer scheme, some may
support some other scheme (e.g. a temporal scheme for audio or video,...).
The interoperability guarantee that this gives is that it is not possible
to construct a fragment identifier that means one thing for one type
and another thing for another type. Either it means something for
a given type, or it's not understood for that given type.

I'm not sure I'm happy with this; defining a minimum that every
+xml type has to support would be very desirable in my eyes.
That's one of the ideas behind the +xml suffix, isn't it.
So how should this minimum look like?

Regards,   Martin.

Date: Mon, 25 Sep 2000 17:04:38 +0200
From: Chris Lilley <[email-masked]>
Organization: W3C
To: Dan Kohn <[email-masked]>
CC: [email-masked], Mark Baker <[email-masked]>
Subject: Re: Conformance value of "+xml"?
Sender: [email-masked]

Dan Kohn wrote:

> The concern with fragment identifiers was that certain media types developed
> before the XLink spec (I remember SVG being mentioned),

SVG was developed concurrently with the XLink spec and is, in fact, the
first W3C specification to use XLink.

However, since you mention fragment identifiers, I suspect you were
thinking of XPointer? SVG supports a subset of XPointer, not the ful spec.

>  might not confirm to
> the later linking spec.  If all it takes to conform to the linking spec is
> to be valid XML, 

No, conformance to XLink requires use of the XLink spec (which SVG for
example does); conformance to XPointer requires an application to conform
to XPointer, and cannot be inferred from looking at the content that is
being pointed into.

> Let me close by quoting the RFC 2119 definitions for MUST and SHOULD, to
> point out that the distance between them is really quite large.  We worked
> hard to only use MUST when interoperability guarantees demanded it:

I think it was interoperability guarantees that Mark was looking for.
However, the point about non-XML applcations MUST NOT be registered with a
+xml suffix seems to at least guarantee that the message body will be a
well formed XML instance.

> For the fifth paragraph I'd recommend changing the wording to reflect
> that for fragment identifiers at least, registrations are free to
> *extend* the syntax, but must at least support the XML syntax;

In the case of SVG, since there seemed to be little prior experience with
the full complexities of XPoinbter, SVG supports a subset of the syntax. So
the uses in an  SVG instance will all conform to the XPointer spec, but the
converse is not true - not all valid XPointers are guaranteed to be
processd by SVG-aware user agents.

--
Chris

Date: Thu, 21 Sep 2000 14:03:42 -0400
From: Mark Baker <[email-masked]>
Organization: Sun Microsystems Inc.
To: [email-masked]
Subject: Re: Conformance value of "+xml"?
Sender: [email-masked]

> The concern with fragment identifiers was that certain media types developed
> before the XLink spec (I remember SVG being mentioned), might not confirm to
> the later linking spec.  If all it takes to conform to the linking spec is
> to be valid XML, than by definition all +xml media types do so, so there's
> no problem with the current draft.  If something extra is required, than the
> SHOULD language is appropriate since some media types may not do so, so
> there's still no problem with the current draft.

After thinking about this some more, I realized that it was fragment
identifiers alone that I was concerned about.  It's too bad XPointer
couldn't be ready in time for this draft to reference normatively, but I
accept your explanation as resolving my issue.

Thanks for the clarification.

MB

From: Dan Kohn <[email-masked]>
To: [email-masked], Mark Baker <[email-masked]>
Subject: RE: Conformance value of "+xml"?
Date: Wed, 20 Sep 2000 23:08:50 -0700
Sender: [email-masked]

I believe the guarantee you are looking for is in the last sentence of the
last paragraph of Section 7:

   The registration process for these media types is described in
   [RFC2048]. The registrar for the IETF tree will encourage new
   XML-based media type registrations in the IETF tree to follow this
   guideline. Registrars for other trees SHOULD follow this convention
   in order to ensure maximum interoperability of their XML-based
   documents. Similarly, media subtypes that do not represent XML
   entities MUST NOT be allowed to register with a '+xml' suffix.

MIME types with a +xml label are XML.  Stated in the negative (i.e., the
contrapositive), it is violation of the spec to send +xml MIME objects that
are not XML.  Note though, that not all XML MIME types are required to use a
+xml label (see Section A15).

That is the main reason for the SHOULDs.  Secondarily, certain registrations
may have additional or slightly different concerns, so it didn't seem
reasonable to constrain them to the identical registration language that we
used.

The concern with fragment identifiers was that certain media types developed
before the XLink spec (I remember SVG being mentioned), might not confirm to
the later linking spec.  If all it takes to conform to the linking spec is
to be valid XML, than by definition all +xml media types do so, so there's
no problem with the current draft.  If something extra is required, than the
SHOULD language is appropriate since some media types may not do so, so
there's still no problem with the current draft.

Let me close by quoting the RFC 2119 definitions for MUST and SHOULD, to
point out that the distance between them is really quite large.  We worked
hard to only use MUST when interoperability guarantees demanded it:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Thanks for the note on the email address, which we'll ask the IESG to fix in
their note to the RFC editor, if they approve the draft when it finishes
last call on 2000-09-27.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

-----Original Message-----
From: Mark Baker [mailto:[email-masked]]
Sent: Wednesday, 2000-09-20 11:49
To: [email-masked]
Subject: Conformance value of "+xml"?

Greetings,

I've been writing the registration of a new media type in the HTML WG
for XHTML using draft-murata-xml-0[78].  In doing this, I've come to the
conclusion that the draft does not provide implementors and authors
enough guarantees in order to be able to do anything more than is done
today without the "+xml" convention.

Before actually implementing the recommendations in this draft, I was
under the impression that using or seeing a media type suffixed with
"+xml" could provide me, as a user agent implementor, certain
guarantees.  However, because of a lack of any MUSTs in 7.1, I am not
guaranteed that *any* of those things in 7.1 actually hold.  It is quite
possible that I could receive a document described as "text/foo+xml",
yet not be able to do anything with it except fallback as text/plain. 
Granted, that isn't any worse than today, but if I wanted that
behaviour, I don't need "+xml" to get it.

Therefore, I'd like to propose the following modifications for 7.1;

- first paragraph; SHOULD to MUST
- second; SHOULD to MUST
- forth; SHOULD to MUST

For the fifth paragraph I'd recommend changing the wording to reflect
that for fragment identifiers at least, registrations are free to
*extend* the syntax, but must at least support the XML syntax;

"These registrations SHOULD also make reference to RFC XXXX in
specifying magic numbers, but MUST reference it for base URIs and use of
the BOM.  Fragment identifier syntax MAY be extended by the
registration, but it MUST at least reference RFC XXXX.

BTW, Appendix C references an incorrect email address for this list,
"[email-masked]".

MB

Date: Wed, 20 Sep 2000 14:48:59 -0400
From: Mark Baker <[email-masked]>
Organization: Sun Microsystems Inc.
To: [email-masked]
Subject: Conformance value of "+xml"?
Sender: [email-masked]

Greetings,

I've been writing the registration of a new media type in the HTML WG
for XHTML using draft-murata-xml-0[78].  In doing this, I've come to the
conclusion that the draft does not provide implementors and authors
enough guarantees in order to be able to do anything more than is done
today without the "+xml" convention.

Before actually implementing the recommendations in this draft, I was
under the impression that using or seeing a media type suffixed with
"+xml" could provide me, as a user agent implementor, certain
guarantees.  However, because of a lack of any MUSTs in 7.1, I am not
guaranteed that *any* of those things in 7.1 actually hold.  It is quite
possible that I could receive a document described as "text/foo+xml",
yet not be able to do anything with it except fallback as text/plain. 
Granted, that isn't any worse than today, but if I wanted that
behaviour, I don't need "+xml" to get it.

Therefore, I'd like to propose the following modifications for 7.1;

- first paragraph; SHOULD to MUST
- second; SHOULD to MUST
- forth; SHOULD to MUST

For the fifth paragraph I'd recommend changing the wording to reflect
that for fragment identifiers at least, registrations are free to
*extend* the syntax, but must at least support the XML syntax;

"These registrations SHOULD also make reference to RFC XXXX in
specifying magic numbers, but MUST reference it for base URIs and use of
the BOM.  Fragment identifier syntax MAY be extended by the
registration, but it MUST at least reference RFC XXXX.

BTW, Appendix C references an incorrect email address for this list,
"[email-masked]".

MB

From: Dan Kohn <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: draft-ietf-roamops-phonebook-xml-05.txt
Date: Thu, 14 Sep 2000 09:56:28 -0700
Sender: [email-masked]

Given that <http://www.ietf.org/internet-drafts/draft-murata-xml-08.txt> is
still in IETF last call, I do not think it is necessary to modify your
draft.

Instead, I would suggest an informational supplement with the registration,
or just making a registration straight to IANA (as described in RFC 2048,
with review on [email-masked]).

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, 2000-09-14 07:04
To: Dan Kohn
Cc: [email-masked]; [email-masked]
Subject: Re: draft-ietf-roamops-phonebook-xml-05.txt

Dan,

Given that this particular document has already been through WG, IESG *and*
IETF last call, how strongly do you feel about this proposed appendix?

PatC
> I would recommend adding an appendix to
>
<http://www.ietf.org/internet-drafts/draft-ietf-roamops-phonebook-xml-05.txt
> > where you register a MIME type for a roamops phonebook based on the
advice
> provided in <http://www.ietf.org/internet-drafts/draft-murata-xml-08.txt>.
> 
> It would appear that application/phonebook+xml may be a good choice.
> 
> 		- dan
> --
> Dan Kohn <mailto:[email-masked]>
> <http://www.dankohn.com>  <tel:+1-650-327-2600>

Reply-To: <[email-masked]>
From: "Glen Zorn" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "Dan Kohn" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: draft-ietf-roamops-phonebook-xml-05.txt
Date: Thu, 14 Sep 2000 08:26:29 -0700
Importance: Normal
Sender: [email-masked]

I'd be a little stronger -- too late, too bad, write another draft.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of [email-masked]
> Sent: Thursday, September 14, 2000 7:04 AM
> To: Dan Kohn
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-ietf-roamops-phonebook-xml-05.txt
> 
> 
> Dan,
> 
> Given that this particular document has already been through WG, 
> IESG *and*
> IETF last call, how strongly do you feel about this proposed appendix?
> 
> PatC
> > I would recommend adding an appendix to
> > 
> <http://www.ietf.org/internet-drafts/draft-ietf-roamops-phonebook-
> xml-05.txt
> > > where you register a MIME type for a roamops phonebook based 
> on the advice
> > provided in 
> <http://www.ietf.org/internet-drafts/draft-murata-xml-08.txt>.
> > 
> > It would appear that application/phonebook+xml may be a good choice.
> > 
> > 		- dan
> > --
> > Dan Kohn <mailto:[email-masked]>
> > <http://www.dankohn.com>  <tel:+1-650-327-2600>
> 
> 
> 

Date: Thu, 14 Sep 2000 07:03:58 -0700 (PDT)
From: "[email-masked]" <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-roamops-phonebook-xml-05.txt
To: Dan Kohn <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Dan,

Given that this particular document has already been through WG, IESG *and*
IETF last call, how strongly do you feel about this proposed appendix?

PatC
> I would recommend adding an appendix to
> <http://www.ietf.org/internet-drafts/draft-ietf-roamops-phonebook-xml-05.txt
> > where you register a MIME type for a roamops phonebook based on the advice
> provided in <http://www.ietf.org/internet-drafts/draft-murata-xml-08.txt>.
> 
> It would appear that application/phonebook+xml may be a good choice.
> 
> 		- dan
> --
> Dan Kohn <mailto:[email-masked]>
> <http://www.dankohn.com>  <tel:+1-650-327-2600>

From: Dan Kohn <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: draft-ietf-roamops-phonebook-xml-05.txt
Date: Wed, 13 Sep 2000 23:14:16 -0700
Sender: [email-masked]

I would recommend adding an appendix to
<http://www.ietf.org/internet-drafts/draft-ietf-roamops-phonebook-xml-05.txt
> where you register a MIME type for a roamops phonebook based on the advice
provided in <http://www.ietf.org/internet-drafts/draft-murata-xml-08.txt>.

It would appear that application/phonebook+xml may be a good choice.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard
Date: Thu, 14 Sep 2000 01:15:15 +0900 (JST)
Lines: 27
Sender: [email-masked]

From: [email-masked]
Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard
Date: Thu, 07 Sep 2000 08:56:12 -0700 (PDT)

> Sounds fine to me. Please submit an updated version of the draft.
> Unfortunately, given that this is a change to requirements language I think
> we'll have to restart the last call, so the sooner the better on this.

After the minor modification, a new I-D has been published. 
Its URL is:

http://www.ietf.org/internet-drafts/draft-murata-xml-08.txt

The second edition of XML 1.0 is being prepared and is expected to be
published in the very near future.  At present, it references to RFC
2376.  If the last call has to be really restarted, the second edition
will probably have to continue to reference to RFC 2376.

Cheers,

IBM Tokyo Research Lab &
International University of Japan, Research Institute

MURATA Makoto

From: Dan Kohn <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard
Date: Fri, 8 Sep 2000 00:06:28 -0700 
Sender: [email-masked]

Ned, as you are the Area Director reviewing this spec, we (the co-authors)
will defer to your judgement on the need to restart the Last Call period.

For obvious reasons, we would rather skip the extra month necessary to do
so.  I will also note that Section 6.1.2 of RFC 2026 doesn't set any
specific guidelines for what level of change does or does not require a
restart of Last Call.  Given that the suggested change does not affect the
normal operation of the protocol (where external parsed entities are
supposed to use their own MIME type), and that the issue comes down to how
deal with any existing implementations that (could possibly) differ from the
new spec, I would suggest that it is not a significant change.  We don't
actually have any examples from the wild of software or messages that would
even be affected by this change.  Again, however, we defer to your judgement
as to whether any changes to requirements language mandates a Last Call
restart.

In either event, we'll be submitting the -08 draft tomorrow.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, 2000-09-07 08:56
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard

> In the IETF-XML-MIME ML, Larry Masinter made proposed to slightly
> revise the latest draft (draft-murata-xml-07.txt).  Dave Peterson
> agreed.

> >    For backward compatibility, application/xml and text/xml MAY,
> >    but SHOULD NOT, also be used for "external parsed entities",
> >    "external DTD subsets", and "external parameter entities".

> > I don't think "MAY but SHOULD NOT" is a valid state in RFC 2119
> > terminology, or called for. How about:

> >   application/xml and text/xml MUST NOT be used for "external parsed
> >   entities", "external DTD subsets", and "external parameter entities".
> >   Note that RFC 2376 (obsoleted) allowed this usage, although
> >   in practice it is likely to be rare.

> I spoke with my co-authors: Dan Kohn and Simon St. Laurent.  We
> have agreed to accept the proposed change.

Sounds fine to me. Please submit an updated version of the draft.
Unfortunately, given that this is a change to requirements language I think
we'll have to restart the last call, so the sooner the better on this.

				Ned

From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard
Date: Fri, 08 Sep 2000 14:02:14 +0900 (JST)
Lines: 23
Sender: [email-masked]

Ned wrote:
> Sounds fine to me. Please submit an updated version of the draft.

I slightly changed Larry's wording, since some external parsed 
entities are well-formed XML documents and are also used as 
XML documents.
 
    application/xml and text/xml MUST NOT be used for "external DTD
    subsets" and "external parameter entities", and MUST NOT be used for
    "external parsed entities" unless they are also well-formed "document
    entities" and used as such.  Note that RFC2376 (obsoleted) allowed
    this usage, although in practice it is likely to be rare.

> Unfortunately, given that this is a change to requirements language I think
> we'll have to restart the last call, so the sooner the better on this.

I am surprised to hear that this slight change requires four week
review again.  But I will follow your instruction.

IBM Tokyo Research Lab &
International University of Japan, Research Institute

MURATA Makoto

From: [email-masked]
Date: Thu, 07 Sep 2000 08:56:12 -0700 (PDT)
Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> In the IETF-XML-MIME ML, Larry Masinter made proposed to slightly
> revise the latest draft (draft-murata-xml-07.txt).  Dave Peterson
> agreed.

> >    For backward compatibility, application/xml and text/xml MAY,
> >    but SHOULD NOT, also be used for "external parsed entities",
> >    "external DTD subsets", and "external parameter entities".

> > I don't think "MAY but SHOULD NOT" is a valid state in RFC 2119
> > terminology, or called for. How about:

> >   application/xml and text/xml MUST NOT be used for "external parsed
> >   entities", "external DTD subsets", and "external parameter entities".
> >   Note that RFC 2376 (obsoleted) allowed this usage, although
> >   in practice it is likely to be rare.

> I spoke with my co-authors: Dan Kohn and Simon St. Laurent.  We
> have agreed to accept the proposed change.

Sounds fine to me. Please submit an updated version of the draft.
Unfortunately, given that this is a change to requirements language I think
we'll have to restart the last call, so the sooner the better on this.

				Ned

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard
Date: Thu, 07 Sep 2000 23:30:37 +0900 (JST)
Lines: 27
Sender: [email-masked]

In the IETF-XML-MIME ML, Larry Masinter made proposed to slightly
revise the latest draft (draft-murata-xml-07.txt).  Dave Peterson 
agreed.

>    For backward compatibility, application/xml and text/xml MAY, 
>    but SHOULD NOT, also be used for "external parsed entities", 
>    "external DTD subsets", and "external parameter entities".
> 
> I don't think "MAY but SHOULD NOT" is a valid state in RFC 2119
> terminology, or called for. How about:
> 
>   application/xml and text/xml MUST NOT be used for "external parsed
>   entities", "external DTD subsets", and "external parameter entities".
>   Note that RFC 2376 (obsoleted) allowed this usage, although
>   in practice it is likely to be rare.

I spoke with my co-authors: Dan Kohn and Simon St. Laurent.  We 
have agreed to accept the proposed change.

Sincerely yours,

IBM Tokyo Research Lab &
International University of Japan, Research Institute

MURATA Makoto (FAMILY Given)

From: [email-masked]
Subject: your imaging supplies
Date: Fri, 5 Sep 1997 00:23:59
Sender: [email-masked]

STATIC SYSTEMS
5334 LAKE VIEW CLUB
ATLANTA GA 30338
770-399-0953

***LASER PRINTER TONER CARTRIDGES***
***FAX AND COPIER TONER***

 
WE ACCEPT GOVERNMENT, SCHOOL,UNIVERSITY AND LARGE CORPORATE
PURCHASE ORDERS. JUST LEAVE YOUR PO # WITH CORRECT BILLING 
AND SHIPPING ADDRESS.

WHY PAY MORE FOR YOUR LASER PRINTER CARTRIDGES?
SAVE FROM 20-40% BY PURCHASING FROM STATIC SYSTEMS. 

ALL CARTRIDGES COME WITH A 90 DAY WARRANTY. WE WILL
IMMEDIATELY REPLACE YOUR CARTRIDGE (NO QUESTIONS ASKED)
IF IT GOES BAD WITHIN 90 DAYS FROM THE DATE OF PURCHASE.

CHECK OUT OUR NEW CARTRIDGE PRICES FOR THE FOLLOWING PRINTERS:

APPLE 
 
  LASER WRITER  PRO 600 OR 16/600         $69
  LASER WRITER SELECT 300,310.360         $69
  LASER WRITER 300, 320                   $54 
  LASER WRITER LS,NT,2NTX,2F,2G & 2SC     $54 
  LASER WRITER 12/640                     $79 

HEWLETT PACKARD 

  LASERJET SERIES 2,3 & 3D (95A)          $49 
  LASERJET SERIES  2P AND 3P (75A)        $54 
  LASERJET SERIES 3SI AND 4SI (91A)       $75 
  LASERJET SERIES 4L AND 4P               $49 
  LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A)  $59 
  LASERJET SERIES 4000 HIGH YIELD  (27X)  $89 
  LASERJET SERIES 4V                      $95 
  LASERJET SERIES 5SI , 8000              $95 
  LASERJET SERIES 5L AND 6L               $49 
  LASERJET SERIES 5P, 5MP, 6P, 6MP        $59 
  LASERJET SERIES 5000 (29A)             $135
  LASERJET SERIES 1100 (92A)              $49 
  LASERJET SERIES 2100 (96A)              $79
  LASERJET SERIES 8100 (82X)		 $145

HP LASERFAX 

  LASERFAX 500, 700, FX1,                 $59 
  LASERFAX 5000, 7000, FX2,               $59 
  LASERFAX  FX3                           $69 
  LASERFAX  FX4                           $79 

LEXMARK 

  OPTRA  4019, 4029  HIGH YIELD          $135 
  OPTRA R, 4039, 4049 HIGH YIELD         $135 
  OPTRA S 4059 HIGH YIELD                $135 
  OPTRA E                                 $59 
  OPTRA  N                               $115 

EPSON 

  EPL-7000, 8000                         $105 
  EPL-1000, 1500                         $105 

CANON 

  LBP-430                                 $49 
  LBP-460, 465                            $59 
  LBP-8 II                                $54 
  LBP-LX                                  $54 
  LBP-MX                                  $95 
  LBP-AX                                  $49 
  LBP-EX                                  $59 
  LBP-SX                                  $49 
  LBP-BX                                  $95 
  LBP-PX                                  $49 
  LBP-WX                                  $95 
  LBP-VX                                  $59 
  CANON FAX L700 THRU L790 FX1            $59 
  CANONFAX L5000 L70000  FX2              $59 

CANON COPIERS 

  PC 20, 25 ETC....                       $89 
  PC 3, 6RE, 7, 11  (A30)                 $69 
  PC 320 THRU 780  (E40)                  $89 

NEC 

  SERIES 2 LASER MODEL 90,95             $105

PLEASE NOTE:

1) ALL OUR CARTRIDGES ARE OEM COMPATABILE.
2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 
3) WE DO NOT FAX QUOTES OR PRICE LISTS.  
5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS
6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS
7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES    
8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES

****OUR  ORDER LINE IS 770-399-0953 ****

****PLACE YOUR ORDER AS FOLLOWS**** :

BY PHONE   770-399-0953 

BY FAX:    770-698-9700 
BY MAIL:   STATIC SYSTEMS
           5334 LAKE VIEW CLUB
           ATLANTA GA 30338

MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 

             1)  YOUR PHONE NUMBER 
             2)  COMPANY NAME 
             3)  SHIPPING ADDRESS 
             4)  YOUR NAME 
             5)  ITEMS NEEDED WITH QUANTITIES 
             6)  METHOD OF PAYMENT. 

N0TE: (PRINTER TRADEMARK NAMES ARE USED ABOVE FOR REFERENCE 
       ONLY AND ARE NOT INTENDED TO INFRINGE ON THOSE TRADEMARKS)