Klotz, Leigh wrote:
Bill,
Thank you for the answer.
I'm being cautious here, because vocabulary integration is one of my main
concerns in the direction Atom is taking, and I hate to see everything
hard-coded with special deference to particular HTML tags. If we can't solve
the problems without
On Friday, April 15, 2005, at 03:51 PM, A. Pagaltzis wrote:
* Antone Roundy <[EMAIL PROTECTED]> [2005-04-15 23:05]:
2) It makes it more difficult to determine the type of data.
We know it's XML, but to find out whether it's a flavor of XML
that we know how to deal with, we have to discover the
nam
Antone Roundy wrote:
Could we drop the xhtml:div requirement in [EMAIL PROTECTED]"xhtml"],
+1
and instead clarify the status of the div that is commonly being put
there (is it part of the content or not?)
+1
by adding an attribute to atom:content
-1
Let me explain my point of view:
With @type="text
* Antone Roundy <[EMAIL PROTECTED]> [2005-04-15 23:25]:
> @container="dispose" is only legal for XML types, whether
> "XHTML", or a MIME type ending in "/xml" or "+xml".
Of course, @container would then obviate the need for treating
XHTML any differently from other XML types (apart from the âhow
* Antone Roundy <[EMAIL PROTECTED]> [2005-04-15 23:05]:
> 2) It makes it more difficult to determine the type of data.
> We know it's XML, but to find out whether it's a flavor of XML
> that we know how to deal with, we have to discover the
> namespace of the content.
Good point, but it can be ad
In case the idea was buried too deeply in my prior email[1], here it is
in it's own message:
Could we drop the xhtml:div requirement in [EMAIL PROTECTED]"xhtml"], and
instead clarify the status of the div that is commonly being put there
(is it part of the content or not?) by adding an attribut
On Friday, April 15, 2005, at 02:30 PM, A. Pagaltzis wrote:
* A. Pagaltzis <[EMAIL PROTECTED]> [2005-04-15 20:20]:
* Antone Roundy <[EMAIL PROTECTED]> [2005-04-15 00:10]:
...
This is XHTML content,
and the default namespace is XHTML's.
I like this. A lot.
One better, with my @type='xml' sugges
* A. Pagaltzis <[EMAIL PROTECTED]> [2005-04-15 20:20]:
> * Antone Roundy <[EMAIL PROTECTED]> [2005-04-15 00:10]:
> >
> > ...
> > > xmlns="XHTML's namespace URI">
> > This is XHTML content,
> > and the default namespace is XHTML's.
> >
>
> I like this. A lot.
One better, with my @type='xml' su
Klotz, Leigh wrote:
I'm being cautious here, because vocabulary integration is one of my
main concerns in the direction Atom is taking, and I hate to see
everything hard-coded with special deference to particular HTML tags.
If we can't solve the problems without recourse to spec changes, we
won't b
Bill,
Thank you for the answer.
I'm being cautious here, because vocabulary integration is one of my main
concerns in the direction Atom is taking, and I hate to see everything
hard-coded with special deference to particular HTML tags. If we can't solve
the problems without recourse to spec c
* Antone Roundy <[EMAIL PROTECTED]> [2005-04-15 00:10]:
>
> ...
> xmlns="XHTML's namespace URI">
> This is XHTML content,
> and the default namespace is XHTML's.
>
I like this. A lot.
* AsbjÃrn Ulsberg <[EMAIL PROTECTED]> [2005-04-15 10:20]:
> Example:
>
>
> ...
> http://www.w3.o
On Friday, April 15, 2005, at 02:14 AM, Asbjørn Ulsberg wrote:
But even though I see it is a major hack, won't putting Content
Constructs inside the target namespace of the embedded content be a
solution to tell what type of content we are embedding without having
to use a 'type' element?
I thi
On Thu, 14 Apr 2005 23:58:05 +0200, Antone Roundy <[EMAIL PROTECTED]>
wrote:
This is XHTML content,
and the default namespace is XHTML's.
This example made me think about another solution for the Content
Constructs of Atom. Today, they all reside in the Atom namespace, which of
course, mak
13 matches
Mail list logo
