Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]

[A. Pagaltzis]

* Bill de hOra <[EMAIL PROTECTED]> [2006-10-04 03:55]:
> A. Pagaltzis wrote:
> >I think given the above background you'll agree that the
> >intent of the document is pretty coherent. 
> 
> I couldn't tell whether new Atom extensions are foreign markup,
> or something else to be dealt with under wrt being
> a "forward-compatible" friendly consumer. It's kind of
> circular.

That’s what I meant. The intent is well thought-out and sharply
defined (in the mathematical sense), but it’s specification in
the document is not very explicit. It could stand to be clarified
a bit so that people don’t have to ask on the list to have
someone from the old boys club educate them before they know how
to read the spec.

Since you’re fresh from newly reading that section, how would it
have had to read in order to convey its meaning clearly?


* Robert Sayre <[EMAIL PROTECTED]> [2006-10-04 04:20]:
> Bill, please show us a bug?

Bugs concerning forward compatibility are unlikely to surface
prior to Atom getting revised in some form. It’d be good if the
spec is clear enough that implementations have a chance to react
interoperably in the eventuality of such revisions.

It’s not some huge roadblocking issue, but neither is it without
merit. If it can be removed with an extra sentence in the spec
and a tweak to another and the opportunity is there, that seems
like a worthwhile small win to me. Polish shows in the details.

> I don't think defining terms until we've got a good subset of
> an English dictionary will make the format more interoperable.

Noone said anything about defining new terms.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]

[Robert Sayre]

Bill de hOra wrote:


A. Pagaltzis wrote:


I think given the above background you'll agree that the intent
of the document is pretty coherent. 


I couldn't tell whether new Atom extensions are foreign markup, or 
something else to be dealt with under wrt being a "forward-compatible" 
friendly consumer. It's kind of circular. In short, I guessed and you 
told me I was wrong.


Bill, please show us a bug? I don't think defining terms until we've got 
a good subset of an English dictionary

will make the format more interoperable.

-Rob

Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]

[Bill de hOra]

A. Pagaltzis wrote:


I think given the above background you'll agree that the intent
of the document is pretty coherent. 


I couldn't tell whether new Atom extensions are foreign markup, or 
something else to be dealt with under wrt being a "forward-compatible" 
friendly consumer. It's kind of circular. In short, I guessed and you 
told me I was wrong.


cheers
Bill

Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]

[A. Pagaltzis]

* Bill de hOra <[EMAIL PROTECTED]> [2006-10-04 01:15]:
> Perhaps this is what's intended by those statements:
> 
> """
> Markup not defined in this document is called "foreign markup"
> """

No, I seem to remember pretty clearly from discussion that what
it means is thus:

Markup not known to the consumer is called "foreign markup"

That is, extension markup the consumer knows to interpret is not
foreign markup. In contradistinction, Atom markup that the
consumer does not know to interpret *is* foreign markup (eg.
attributes from a hypothetical future version of Atom).

The document then sets forth how foreign markup should be
interpreted, ie. basically what the consumer should do on finding
things in a feed that it doesn't understand.

> I don't think the document can forward to proposed without
> clarification. Also, "forward-compatible" is mentioned, but not
> defined - it's not possible to make a safe assumption on what
> it means, since it's relative to whatever "foreign markup" is.
> I assume "unrecognized" and "unknown" are synonymous.

I think given the above background you'll agree that the intent
of the document is pretty coherent. A clarification that makes
this background explicit would undoubtedly be helpful, though.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]

[Robert Sayre]

Bill de hOra wrote:
I don't think the document can forward to proposed without 
clarification. Also, "forward-compatible" is mentioned, but not 
defined - it's not possible to make a safe assumption on what it 
means, since it's relative to whatever "foreign markup" is. I assume 
"unrecognized" and "unknown" are synonymous. 


None of these seem pressing to me. I agree that it's muddy, but I 
haven't seen any interoperability problems result. Have you?


-Rob

Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]

[Bill de hOra]

Robert Sayre wrote:


I think we should move the format to Draft Standard by clearing up any 
errata and adding two attributes: 'dir' and 'unicode-bidi', as defined 
in XHTML.


Thoughts?


"Foreign markup" is ambiguous.

[[[
Markup  from other vocabularies ("foreign markup") can be used in an 
Atom Document.

]]]

[[[
For the purposes of this  discussion, unrecognized markup from the Atom 
vocabulary will be  considered "foreign markup".

]]]

Perhaps this is what's intended by those statements:

"""
Markup not defined in this document is called "foreign markup"
"""

I don't think the document can forward to proposed without 
clarification. Also, "forward-compatible" is mentioned, but not defined 
- it's not possible to make a safe assumption on what it means, since 
it's relative to whatever "foreign markup" is. I assume "unrecognized" 
and "unknown" are synonymous.


cheers
Bill

Re: Atom Syndication Format To Draft Standard?

[Martin Duerst]

At 04:10 06/10/03, Julian Reschke wrote:

>Independantly of that, what do we do with all the normative references to 
>proposed standards...:

>RFC3987: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible 
>with this document's standard level!

I've definitely thought about moving that a level forward, but that
may take another few months or so.

Regards,Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp   mailto:[EMAIL PROTECTED] 

Re: Atom and bidi (was: Re: Atom Syndication Format To Draft Standard?)

[David Powell]

Tuesday, October 3, 2006, 1:55:31 AM, I wrote:

> As we depend on Unicode, then we can't really stop people from using
> Unicode bidi. We can't stop people from using HTML/XHTML bidi. Or even
> CSS bidi controls. I think we should think carefully before we
> introduce yet another method for bidi text.

Hmm, that sounded a bit odd. I don't want to "stop people from using
bidi"...

I was trying to say that implementations can support Unicode bidi and
HTML bidi today without any change to the spec, and that they seem
more powerful than an Atom bidi attribute.

-- 
Dave

Re: Atom and bidi (was: Re: Atom Syndication Format To Draft Standard?)

[Karl Dubost]

Le 3 oct. 06 à 08:20, James M Snell a écrit :

I think the suggestion of adding a dir attribute is a very good idea.
The great thing is that it can be done without any significant  
backwards
compatibility concerns.  The definition of the attribute is simple  
enough:


  atomCommonAttributes =
  attribute xml:base { atomUri }?,
  attribute xml:lang { atomLanguageTag }?,
  attribute dir { "rtl" | "ltr" }?,
  undefinedAttribute*

The attribute establishes the base direction of the text content of an
element (and plain text attributes, e.g. category/@label) and is  
pretty

much identical in form to XHTML's dir attribute.


dir attribute in HTML.
http://www.w3.org/TR/html4/struct/dirlang.html#h-8.2

Though in Unicode 5.0  which has been just published
[[[
In UAX #9, "Bidirectional Algorithm," for better interoperability,
the algorithm was modified to tighten up the conformance requirements
for using mirrored glyphs for characters. Higher level protocols are
discouraged, due to interoperability and security considerations. The
definition of directional run was changed to be the same as level
run, and the use of soft-hyphen with bidi text was clarified.
]]] -- Unicode 5.0.0
http://www.unicode.org/versions/Unicode5.0.0/
Tue, 29 Aug 2006 17:33:36 GMT


Maybe Martin or Richard can give us more information about it.



--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
  QA Weblog - http://www.w3.org/QA/
 *** Be Strict To Be Cool ***

Re: Atom and bidi (was: Re: Atom Syndication Format To Draft Standard?)

[David Powell]

Tuesday, October 3, 2006, 12:20:01 AM, James Snell wrote:

> I think the suggestion of adding a dir attribute is a very good idea.
> The great thing is that it can be done without any significant backwards
> compatibility concerns.  The definition of the attribute is simple enough:

>   atomCommonAttributes =
>   attribute xml:base { atomUri }?,
>   attribute xml:lang { atomLanguageTag }?,
>   attribute dir { "rtl" | "ltr" }?,
>   undefinedAttribute*


In the context of Atom, what's the problem with the Unicode bidi
control characters?

I suspect that browsers and standard OS text input widgets have better
support for Unicode bidi, than they do for a currently non-existing
Atom attribute.

Which elements would this help?

  content, subtitle, summary, rights and title support HTML, so this
  wouldn't be necessary for them.

  updated, published, logo, id, and icon I would guess can cope
  without.

  extensions are responsible for their own namespace, I don't think
  that we need to say what attributes can appear on an extension.


I think [EMAIL PROTECTED], [EMAIL PROTECTED], and [EMAIL PROTECTED] are the only
attributes that would really benefit.

Wouldn't Unicode bidi be more powerful than a single direction
element, that would restrict the field to a single direction?

As we depend on Unicode, then we can't really stop people from using
Unicode bidi. We can't stop people from using HTML/XHTML bidi. Or even
CSS bidi controls. I think we should think carefully before we
introduce yet another method for bidi text.  Especially one that will
be incompatible with all existing Atom consumers.


-- 
Dave

Atom and bidi (was: Re: Atom Syndication Format To Draft Standard?)

[James M Snell]

I think the suggestion of adding a dir attribute is a very good idea.
The great thing is that it can be done without any significant backwards
compatibility concerns.  The definition of the attribute is simple enough:

  atomCommonAttributes =
  attribute xml:base { atomUri }?,
  attribute xml:lang { atomLanguageTag }?,
  attribute dir { "rtl" | "ltr" }?,
  undefinedAttribute*

The attribute establishes the base direction of the text content of an
element (and plain text attributes, e.g. category/@label) and is pretty
much identical in form to XHTML's dir attribute.

I'm not 100% certain, but we'd likely be better off limiting the
definition such that only "Language Sensitive" elements and attributes
are affected by the dir attribute.

In any case, +1 from me.

- James

Robert Sayre wrote:
> 
> I think we should move the format to Draft Standard by clearing up any
> errata and adding two attributes: 'dir' and 'unicode-bidi', as defined
> in XHTML.
> 
> Thoughts?
> 
> Robert Sayre
> 
> 

Re: Atom Syndication Format To Draft Standard?

[Lisa Dusseault]

The Draft Standard requirement for demonstrated interoperability for all features is documented in RFC2026.  It's that requirement which leads to the popular conclusion that in many cases, adding a new feature is incompatible with moving to Draft Standard at the same time -- that popular conclusion is part of the folklore, not part of the requirements, which is appropriate. You could draw a different conclusion and argue for that conclusion and might meet with some success, because determining sufficient "demonstrated  interoperability" is sometimes going to be a judgement call anyway.LisaOn Oct 2, 2006, at 11:23 AM, Robert Sayre wrote: That's unfortunate. A documented process is a requirement for open standards development, in the opinion of many   

Re: Atom Syndication Format To Draft Standard?

[Robert Sayre]

Paul Hoffman wrote:

At 6:23 PM + 10/2/06, Robert Sayre wrote:
That's unfortunate. A documented process is a requirement for open 
standards

development, in the opinion of many


If it is a true requirement, then I guess the IETF is an abysmal 
failure. Oh, well.




Well, openness is only one metric.



"needed to display" is often an issue the IETF ignores, so we might 
avoid it if the desire is to get to Draft Standard.


But Julian's second message needs to be dealt with first, and I assure 
you that many of those documents are not going to be going to Draft 
Standard any time soon (if ever) because there is no energy to test 
every required feature in the documents.



Well, I figured it might make sense to advance something that pretty 
much works. I now see how foolish that idea was. Cycling at proposed 
will be fine.


Robert Sayre

Re: Atom Syndication Format To Draft Standard?

[Paul Hoffman]

At 6:23 PM + 10/2/06, Robert Sayre wrote:

That's unfortunate. A documented process is a requirement for open standards
development, in the opinion of many


If it is a true requirement, then I guess the IETF is an abysmal 
failure. Oh, well.


OTOH, some folks in the IETF are trying to meet the desire by doing a 
better job of codifying what is and is not the process. Others, I 
must admit, are not trying at all.



There is one mistake in the Relax NG (atom common attributes on author or
something) and at least one section that is somewhat unclear around 
the external

div in XHTML.


I believe both of those would be considered clarifications, and thus 
not prevent the movement to Draft Standard.



The i18n attributes seem needed to display text without a guess based on
xml:lang.  Maybe we don't even need unicode-bidi. I don't think it would be
smart to take other features.


"needed to display" is often an issue the IETF ignores, so we might 
avoid it if the desire is to get to Draft Standard.


But Julian's second message needs to be dealt with first, and I 
assure you that many of those documents are not going to be going to 
Draft Standard any time soon (if ever) because there is no energy to 
test every required feature in the documents.

Re: Atom Syndication Format To Draft Standard?

[James M Snell]

I would definitely agree that having a dir attribute would be a good
thing. (would be even better if it were defined as xml:dir but...
whatever).

I'm not so sure about unicode-bidi.

- James

Robert Sayre wrote:
> [snip]
> The i18n attributes seem needed to display text without a guess based on
> xml:lang.  Maybe we don't even need unicode-bidi. I don't think it would be
> smart to take other features.
> 
> Robert Sayre
> 
> 
> 
> 

Re: Atom Syndication Format To Draft Standard?

[Julian Reschke]

Paul Hoffman schrieb:


At 3:01 AM -0400 10/2/06, Robert Sayre wrote:
I think we should move the format to Draft Standard by clearing up any 
errata and adding two attributes: 'dir' and 'unicode-bidi', as defined 
in XHTML.


We can't both add features and move to Draft Standard at the same time. 
If we add features, we would recycle at Proposed Standard. Errata that 
are truly that and not technical changes can be made when moving to 
Draft Standard.

> ...

Independantly of that, what do we do with all the normative references 
to proposed standards...:



Normative References:
REC-html401-19991224: [REC] ok
RFC4288: [BEST CURRENT PRACTICE] (-> BCP0013)
RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014)
RFC2822: [PROPOSED STANDARD] -- intended standards level of DRAFT 
incompatible with this document's standard level!
RFC2854: [INFORMATIONAL] -- intended standards level of DRAFT 
incompatible with this document's standard level!
RFC3023: [PROPOSED STANDARD] -- intended standards level of DRAFT 
incompatible with this document's standard level!

RFC3066: [BEST CURRENT PRACTICE] obsoleted by RFC4646 RFC4647
RFC3339: [PROPOSED STANDARD] -- intended standards level of DRAFT 
incompatible with this document's standard level!
RFC3548: [INFORMATIONAL] -- intended standards level of DRAFT 
incompatible with this document's standard level!

RFC3986: [STANDARD] (-> STD0066)
RFC3987: [PROPOSED STANDARD] -- intended standards level of DRAFT 
incompatible with this document's standard level!

REC-xml-20040204: [REC] ok
REC-xml-c14n-20010315: [REC] ok
REC-xml-exc-c14n-20020718: [REC] ok
REC-xml-infoset-20040204: [REC] ok
REC-xml-names-19990114: [REC] ok
REC-xmlbase-20010627: [REC] ok
REC-xmldsig-core-20020212: [REC] ok
REC-xmlenc-core-20021210: [REC] ok
REC-xhtml-modularization-20010410: document unknown

Informative References:
ISO.8601.1988: not checked
RELAX-NG: not checked
RFC2434: [BEST CURRENT PRACTICE] (-> BCP0026)
NOTE-datetime-19980827: document unknown
REC-xmlschema-2-20041028: [REC] ok


?

Best regards, Julian

Re: Atom Syndication Format To Draft Standard?

[Julian Reschke]

Paul Hoffman schrieb:

Dang, where'd that rule come from?


Probably RFC 2026, but if not there, it is certainly in the folklore of 
How Things Are Done.

...


I thought this is possible if interop is demonstrated...

> ...

Best regards, Julian

Re: Atom Syndication Format To Draft Standard?

[Robert Sayre]

Paul Hoffman <[EMAIL PROTECTED]> writes:

> 
> Probably RFC 2026, but if not there, it is certainly in the folklore 
> of How Things Are Done.

That's unfortunate. A documented process is a requirement for open standards
development, in the opinion of many



> 
> >It would probably be easier to add them in a separate document, huh?
> 
> Maybe, but that would then confuse the issue by having two docs 
> people would expect to have read in order to do the format. Given the 
> very marginal value of Draft Standard, we should probably just revise 
> and recycle at Proposed rather than split into two.

There is one mistake in the Relax NG (atom common attributes on author or
something) and at least one section that is somewhat unclear around the external
div in XHTML. 

The i18n attributes seem needed to display text without a guess based on
xml:lang.  Maybe we don't even need unicode-bidi. I don't think it would be
smart to take other features.

Robert Sayre

Re: Atom Syndication Format To Draft Standard?

[Paul Hoffman]

At 11:17 AM -0400 10/2/06, Robert Sayre wrote:

Paul Hoffman wrote:

At 3:01 AM -0400 10/2/06, Robert Sayre wrote:
I think we should move the format to Draft Standard by clearing up 
any errata and adding two attributes: 'dir' and 'unicode-bidi', as 
defined in XHTML.


We can't both add features and move to Draft Standard at the same time.


Dang, where'd that rule come from?


Probably RFC 2026, but if not there, it is certainly in the folklore 
of How Things Are Done.



It would probably be easier to add them in a separate document, huh?


Maybe, but that would then confuse the issue by having two docs 
people would expect to have read in order to do the format. Given the 
very marginal value of Draft Standard, we should probably just revise 
and recycle at Proposed rather than split into two.

Re: Atom Syndication Format To Draft Standard?

[Robert Sayre]

Bjoern Hoehrmann wrote:


I "think" that XHTML does not define an 'unicode-bidi' attribute.
Do you mean, for 'unicode-bidi', "as defined in CSS 2.1"?
  

Sure.


Elliotte Harold wrote:


Which elements would these be attached to? 


All of them.


Paul Hoffman wrote:

At 3:01 AM -0400 10/2/06, Robert Sayre wrote:
I think we should move the format to Draft Standard by clearing up 
any errata and adding two attributes: 'dir' and 'unicode-bidi', as 
defined in XHTML.


We can't both add features and move to Draft Standard at the same time.


Dang, where'd that rule come from? It would probably be easier to add 
them in a separate document, huh?


Robert Sayre

Re: Atom Syndication Format To Draft Standard?

[Paul Hoffman]

At 3:01 AM -0400 10/2/06, Robert Sayre wrote:
I think we should move the format to Draft Standard by clearing up 
any errata and adding two attributes: 'dir' and 'unicode-bidi', as 
defined in XHTML.


We can't both add features and move to Draft Standard at the same 
time. If we add features, we would recycle at Proposed Standard. 
Errata that are truly that and not technical changes can be made when 
moving to Draft Standard.

Re: Atom Syndication Format To Draft Standard?

[Elliotte Harold]

Robert Sayre wrote:


I think we should move the format to Draft Standard by clearing up any 
errata and adding two attributes: 'dir' and 'unicode-bidi', as defined 
in XHTML.




Which elements would these be attached to?

Also, I'm not familiar with the unicode-bidi attribute. Do you have a 
reference for it? Which version of XHTML is that in? Do you mean the CSS 
unicode-bidi property?


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Re: Atom Syndication Format To Draft Standard?

[Eric Scheid]

On 2/10/06 5:01 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:

> I think we should move the format to Draft Standard by clearing up any
> errata and adding two attributes: 'dir' and 'unicode-bidi', as defined
> in XHTML.

add @attr where?

e.

Re: Atom Syndication Format To Draft Standard?

[James M Snell]

Robert Sayre wrote:
> 
> I think we should move the format to Draft Standard by clearing up any
> errata and adding two attributes: 'dir' and 'unicode-bidi', as defined
> in XHTML.

Are you suggesting adding these to the common attributes or to Text
constructs and atom:content specifically?

- James

Re: Atom Syndication Format To Draft Standard?

[Bjoern Hoehrmann]

* Robert Sayre wrote:
>I think we should move the format to Draft Standard by clearing up any 
>errata and adding two attributes: 'dir' and 'unicode-bidi', as defined 
>in XHTML.
>
>Thoughts?

I "think" that XHTML does not define an 'unicode-bidi' attribute.
Do you mean, for 'unicode-bidi', "as defined in CSS 2.1"?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Atom Syndication Format To Draft Standard?

[Robert Sayre]

I think we should move the format to Draft Standard by clearing up any 
errata and adding two attributes: 'dir' and 'unicode-bidi', as defined 
in XHTML.


Thoughts?

Robert Sayre