Subject: Re: atom:type, xsl:output

From: James Cerra <[email-masked]>
Date: Wed, 25 May 2005 20:23:12 -0700 (PDT)

Henri Sivonen,

> > If the intended Atom content contains essential comments,
> 
> There should be no such thing as essential comments. The XML spec does 
> not require XML processors to report comments to the app. Hence, 
> comments are inappropriate for transferring essential data.

Yes, but MSIE^H^H^H^Hsome xml processors (cough  cough) still inappropriately
use comments for that purpose.  Then there are example XML documents (i.e. for
tutorials) that sometimes require comments be preserved.  So although it is not
required by XML processors, it is nice to not introduce incompatibility with
that optional part of the spec.  Finally if you are posting content associated
with an entry with the Atom API, then it is important that any documents
uploaded are not modified.

(Besides at worst this is a non-issue if no comments are ever essential.)

> > processing instructions,
> 
> These could be supported in embedded content if the Atom spec said PIs 
> in atom:content belong in content and should not be acted upon by the 
> Atom processor.

I don't like this condition.  Any content will be read by XML processors before
being handed to an Atom processor.  So the generic XML processor will not be
able to differentiate between PIs that are significant - and thus should be
processed by their processors - from those which should be passed through.

> > entities
> 
> Entities can be flattened.

Again, as with comments, I agree in principle, but in practice some processors
depend on them.

> > DOCTYPE declaration(s)
> 
> If DOCTYPE is essential for the receiving app, you've got bigger 
> problems than Atom. Hardwiring IDness based on namespaces is more 
> practical than relying on DTD-based data typing.

I'm not necessarily talking about external document type definitions. 
Preventing DOCTYPEs would cause incompatibilities with XML well-formedness
processing.  From the spec:

"[Definition: While they are not required to check the document for validity,
they are REQUIRED to process all the declarations they read in the internal DTD
subset and in any parameter entity that they read, up to the first reference to
a parameter entity that they do not read; that is to say, they MUST use the
information in those declarations to normalize attribute values, include the
replacement text of internal entities, and supply default attribute values.]"

Some RDF/XML processors already put internal DOCTYPE declarations to make the
content more readable.  There is nothing intrinsically bad about DOCTYPE
sections, they provide hints to validating XML processors about validity and
can save time, space, and increase readability.

Remember that anything compatible with XML MUST allow its optional features to
be in the markup (even if they are just ignored).  So if you disallow DOCTYPE
sections, then you can't claim to support XML.

Anything that could have any chance of dataloss - in this case, the loss of XML
comments, PIs, and XML and DOCTYPE declarations – is bad.  Your comment is a
good design pattern for XML based specifications, but in general they don't
have to follow that rule of thumb.  Besides, I don't want the implementors to
get any bad ideas so explicitly stating these things disenfranchises that
behavior from being acceptable from the beginning.

--
Jimmy Cerra
https://nemo.dev.java.net

__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 26 May 2005 11:09:26 +0300

On May 26, 2005, at 06:23, James Cerra wrote:

> use comments for that purpose.

I am not familiar with that. What purpose exactly? Why should Atom 
support it?

> Then there are example XML documents (i.e. for tutorials) that 
> sometimes require comments be preserved.

If you want people to read the source as is, it would make sense to 
make it text/plain or put the source snippets in <code> or <pre> in an 
(X)HTML tutorial.

> Finally if you are posting content associated with an entry with the 
> Atom API, then it is important that any documents uploaded are not 
> modified.

I think Atom processors should not be required to preserve 
serialization artifacts. That is, IMO, they should not be required to 
care about anything that is not exposed via SAX2 ContentHandler with 
qNames ignored.

> processed by their processors - from those which should be passed 

Vanilla XML processors don't act on PIs. They report them to the 
application--in this case the Atom processor.

> Again, as with comments, I agree in principle, but in practice some 

Depending on an entity reference and not being able to accept the 
straight replacement text is just wrong.

> replacement text of internal entities, and supply default attribute 

That's a non-issue. You don't just throw away the DOCTYPE but parse the 
original document with it and reserialize as a DOCTYPEless fragment. 
You don't lose well-formedness or content. You only lose the shallow 
attribute data typing provided by the DTD.

> content more readable.

Atom's main purpose is to facilitate software to software 
communication. When interop or implementation ease and readability 
conflict, readability should yield.

> There is nothing intrinsically bad about DOCTYPE sections

Yes, there is. On the Web you cannot trust that the recipient is using 
an XML processor that processes the DOCTYPE beyond checking the 
internal subset for well-formedness. An optional feature that does not 
degrade gracefully when not supported is bad. DOCTYPE is such a 
feature. In the cases where the DOCTYPE can be gracefully ignored, the 
DOCTYPE is pointless.

> sections, then you can't claim to support XML.

Atom is not claiming that you could embed the literal source of any XML 
doc. You can embed the stuff that canonicalization would preserve.

> comments, PIs, and XML and DOCTYPE declarations – is bad.

Would you consider changes in the order of attributes and the white 
space between attributes data loss as well?

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 26 May 2005 15:40:24 +0200

* James Cerra <[email-masked]> [2005-05-26 05:35]:
> Yes, but MSIE^H^H^H^Hsome xml processors (cough  cough) still
> inappropriately use comments for that purpose.  Then there are
> example XML documents (i.e. for tutorials) that sometimes
> require comments be preserved.
> 
> Again, as with comments, I agree in principle, but in practice
> some processors depend on them.

I do not consider it at all wise to legislate anything in the
Atom spec to address these cases.

Nothing prevents anyone from writing a generator or pre- or
postprocessor for Atom documents to cater to the needs of their
particular brand of broken software. Wrangling that particular
piece of broken software however is their job; not ours nor the
Atom spec’s.

Regards,
-- 
Aristotle

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 26 May 2005 15:43:35 +0200

* Henri Sivonen <[email-masked]> [2005-05-26 10:20]:
> >inappropriately use comments for that purpose.
> 
> I am not familiar with that. What purpose exactly? Why should
> Atom support it?

http://msdn.microsoft.com/workshop/author/dhtml/overview/ccomment_ovw.asp

They are parsed in HTML documents; I have no idea if IE actually
respects these in XML documents.

Regards,
-- 
Aristotle

---

From: James Cerra <[email-masked]>
Date: Fri, 27 May 2005 19:28:05 -0700 (PDT)

Henri Sivonen,

> I am not familiar with that. What purpose exactly? Why should Atom 

MSIE conditional comments.  See other person's reply.

> make it text/plain or put the source snippets in <code> or <pre> in an 

Except when it is a live example.  Or when posting XHTML or XML content that is
intended to be embedded (via object element) as a seperate, child document.  It
seems silly to allow anything NOT xml to be embedded unmodified (i.e. PNGs,
sounds), while no XML content can have that guarantee.

And yes: I know that Atom is not FTP or HTTP.  I'm looking at the Atom entry
uploader's POV rather than the downloader's perspective.  The Atom API is a way
to simplify managing web sites: it would be silly to make it unusable for
associating XML in general while allowing any other type to be unmodified.

> care about anything that is not exposed via SAX2 ContentHandler with 

So do I.  That's why the spec should state that any XML fragments embedded into
atom:content as an XML tree become part of that tree.  So PIs become associated
with the Atom document rather than the content, for example.  If the entry MUST
be preserved unmodified (Author's intention), the spec should either specify
that it must be associated externally via @src or encoded via entities or
base64 like any other non-xml-compatible formats in the current draft.

> application--in this case the Atom processor.

So Atom Processors MUST be between any XML and PI processor stages?  That
sucks!  It means just to display Atom, I can't use a generic XSLT processor
like Saxon or MSIE.

> straight replacement text is just wrong.

I agree.  I'm just bringing up possible incompatibilities for debate!

> attribute data typing provided by the DTD.

Well, that data could be valuable.  Some situations require them, and it would
be really nice to have optional DOCTYPE info kept with the fragment.  With
DOCTYPE information associated with embedded content, it becomes possible to
transform entries into valid XML or HTML documents.  Some apps change their
behavior with well-formed and valid modes.  DOCTYPE switching may be evil, but
it is currently a necessary evil.  I see this as low risk (it doesn't break
anything and could even be an OPTIONAL feature) while easing the pain when
dealing with the existing web.

> conflict, readability should yield.

That's why I proposed they should be externally referenced (or base64ed), so
the Atom processor doesn't touch them!  This is a hint to authors on how to
avoid a common error.

> feature. In the cases where the DOCTYPE can be gracefully ignored, the 

No, any well formed XML processor MUST expand internal entities and add
replaced attributes as well.  This is NOT OPTIONAL.

> doc. You can embed the stuff that canonicalization would preserve.

Yet you can do that with PNG, PDF, or other content via base 64 encodings.  It
is silly to allow that for them and not XML.

> space between attributes data loss as well?

I wouldn't in general, but XML never claimed to encode that data in the first
place.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Henri Sivonen <[email-masked]>
Date: Sat, 28 May 2005 11:36:16 +0300

> MSIE conditional comments.  See other person's reply.

I thought they were for text/html tag soup only. Anyway, I think Atom 
should not try to enable such bogosity in XML.

> to simplify managing web sites:

Is it really? Straight bytes over HTTP PUT seems a lot simpler to me 
than Base64 in an XML envelope over HTTP PUT.

> sucks!  It means just to display Atom, I can't use a generic XSLT 

What PIs do they act on besides the style sheet PI, which must appear 
in the prolog (so conforming tools should not act on it if it appears 
within atom:content)?

> I agree.  I'm just bringing up possible incompatibilities for debate!

I don't think that's an incompatibility that deserves catering for.

> Well, that data could be valuable.

IDness is. For practical purposes, the other stuff is not. There are 
other solutions for IDness.

> With DOCTYPE information associated with embedded content, it becomes 
> possible to
> transform entries into valid XML or HTML documents.

What do you need valid documents for if the validity is just an 
property internal to the document? That is, the document is valid 
according to its own rules as opposed to conforming to the rules 
required by some downstream software.

> Some apps change their behavior with well-formed and valid modes.

That seems like a bad idea. Can you give examples?

> DOCTYPE switching may be evil, but it is currently a necessary evil.

It is not a necessary evil for XML. I am strongly against any Atom 
feature motivated by or designed for enabling and/or encouraging 
doctype sniffing in XML.

Please see http://hsivonen.iki.fi/doctype/#xml

> I see this as low risk (it doesn't break anything and could even be an 
> OPTIONAL feature)

Optional features always have a cost. Also, they tend to become de 
facto mandatory for everyone or de facto useless for everyone.

> the Atom processor doesn't touch them!  This is a hint to authors on 

Base64 XML in XML was rejected earlier in the working group process.

> replaced attributes as well.  This is NOT OPTIONAL.

So is expat non-conforming?

> is silly to allow that for them and not XML.

Looks like straight HTTP without an Atom envelope in between suits your 
needs better.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 28 May 2005 11:16:59 +0100

> base64 like any other non-xml-compatible formats in the current draft.

This is why MIME is still a good idea.

cheers
Bill

---

From: James Cerra <[email-masked]>
Date: Sun, 29 May 2005 18:08:36 -0700 (PDT)

Henri Sivonen,

> should not try to enable such bogosity in XML.

I don't think Atom should take a position if it doesn't have to.

> than Base64 in an XML envelope over HTTP PUT.

In this case, the simplier grammar option is a more complex job.  First, Atom
already supports this with every other MIME type including HTML, but not
anything that is XML.  Why?  Second, if your content is a literal document of
*any* type then:

** steps with envelope **
1. PUT doc-with-envelope.atom to http://uri1.com.
2. PUT doc-with-envelope.atom to http://uri2.com with user, pass.

** steps without envelope **
1. PUT doc-referencing-uri1.atom to http://uri1.com.
2. PUT image.png to http://uri1.com/images/image.png.
3. Modify doc-referencing-uri1.atom to reference uri2.
4. PUT doc-referencing-uri2.atom to http://uri2.com with user, pass.
5. PUT image.png to http://uri2.com/_title_of_entry_/image.png with user, pass.

That is, including it in an atom:content element and sending that off to the
server allows you to send that off to another server with ***only changing the
Atom document's PUT uri*** rather than sending the external document according
to each server's implementation (i.e. uri or other means).  Having a standard
way of sending files for a blog - like a picture blog for instance - is really
nice.  Otherwise it is much harder to change servers or atom processors.

> in the prolog (so conforming tools should not act on it if it appears 

You are correct about <?xml-stylesheet?> but in general there could be others. 
XSLT stylesheets can use them for flexibility, for example.  Better not to make
assumptions about their behavior.

> I don't think that's an incompatibility that deserves catering for.

Why not?  Why be incompatible for the sake of incompatibility?  That's just
asking for trouble when Atom is used in ways not originally envisioned (and
there always are).

> other solutions for IDness.

I don't understand why?

> required by some downstream software.

Valid as in, this is valid HTML 3.2 or that is valid HTML 5 or this is valid
HTML 4.01 transitional.  Right now it is impossible to specify that for
atom:content[@type="html"] content, but that doctype information is esssencial
for properly interpreting the semantics of the HTML content, and possibly how
to write it out as a web page.  :-(  If you make me guessing I'll go mad!  :-)

> Please see http://hsivonen.iki.fi/doctype/#xml

See reply immediately above.  HTML currently uses doctypes for switching
between versions of the langauage.  There is no other way to properly interpret
content without guessing in the current drafts.  That is a worse sin inflicted
upon programmers, than allowing the subset that do rendering to do naughty
DOCTYPE sniffing.

> facto mandatory for everyone or de facto useless for everyone.

Yes, but this is a low cost as long as the semantics of having the doctype
specified and not having it specified are clearly stated.  The cost of not
including it is having implementions differing on how they interpret the xml. 
The result is that people will become locked into particular atom processors
and the practical spec will diverge from the standard.  That would be a failure
of Atom.

> Base64 XML in XML was rejected earlier in the working group process.

It is in the latest public draft that I read.  What is replacing it?

> So is expat non-conforming?

If it doesn't, then it is non-conforming.  That's how non-validating XML
processors are defined by the spec.  I quote from section 5.1 paragraph 4:

[Definition: While they are not required to check the document for validity,
they are REQUIRED to process all the declarations they read in the internal DTD
subset and in any parameter entity that they read, up to the first reference to
a parameter entity that they do not read; that is to say, they MUST use the
information in those declarations to normalize attribute values, include the
replacement text of internal entities, and supply default attribute values.]

There is no room for any other interpretation, I think.

> Looks like straight HTTP without an Atom envelope in between suits your 

It is inflexible working at such low protocols; you should not need WS-* or a
standard REST format (and I know of no way to specify REST URIs/requests in a
standard format anyway) to switch between blogging servers/clients.  See second
reply.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 30 May 2005 16:47:31 +0200

* James Cerra <[email-masked]> [2005-05-30 03:20]:
> > >> Depending on an entity reference and not being able to
> > >> accept the straight replacement text is just wrong.
> > >
> Why not?  Why be incompatible for the sake of incompatibility?
> That's just asking for trouble when Atom is used in ways not
> originally envisioned (and there always are).

That’s bogus. Some software generates or processes non-wellformed
XML. Should Atom cater to that too? If not, where do you draw the
line between somewhat-broken software that Atom should support
and really-broken software that it should not?

> HTML currently uses doctypes for switching between versions of
> the langauage.

No, it doesn’t. Browsers do so, but only as a hack; the idea is
that an author who puts a DOCTYPE declaration in their document
*probably* cares about validity and so his document should
*probably* be treated as strict standards compliance requires.
But there is nothing in any spec that justifies this behaviour.

> There is no other way to properly interpret content without
> guessing in the current drafts.  That is a worse sin inflicted
> upon programmers, than allowing the subset that do rendering to
> do naughty DOCTYPE sniffing.

You don’t seem to understand XML. XML has something called
namespaces. Use them.

> > > No, any well formed XML processor MUST expand internal
> > > entities and add replaced attributes as well.  This is NOT
> > > OPTIONAL.
> > 
> If it doesn't, then it is non-conforming.

Wrong.

> That's how non-validating XML processors are defined by the
> spec.  I quote from section 5.1 paragraph 4:
> 
> [Definition: While they are not required to check the document
> for validity, they are REQUIRED to process all the declarations
> they read in the internal DTD subset and in any parameter
                   ^^^^^^^^     ^^^^^^
> entity that they read, up to the first reference to a parameter
         ^^^^^^^^^^^^^^
> entity that they do not read; that is to say, they MUST use the
         ^^^^^^^^^^^^^^^^^^^^^
> information in those declarations to normalize attribute
> values, include the replacement text of internal entities, and
> supply default attribute values.]
> 

Nowhere is a non-validating processor REQUIRED to read an
external DTD in the spec. Only *internal* declarations MUST be
processed and references resolved.

Regards,
-- 
Aristotle