Subject: PaceNoInfoSet

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Jul 2004 09:43:40 -0700

What is "an application of XML 1.0 and XML Namespaces"? That's like 
saying something is "an application of ASCII."

Does this proposal have any affect on implementations or conformance?

--
Mark Nottingham     http://www.mnot.net/

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 02 Jul 2004 17:51:02 +0100

> saying something is "an application of ASCII."

I guess it's meant to entail "not an application of the XML 
Infoset". Closed world Assumption and all that.

> Does this proposal have any affect on implementations or conformance?

Perhaps it's meant to stop people calling a non-XML serialization of 
Atom, "Atom". Binary XML Brand Management Permathread and all that.

cheers
Bill

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 02 Jul 2004 19:12:28 +0200

> saying something is "an application of ASCII."

I agree. The wording is really odd. Also, I can't see what we gain from  
disallowing other serializatin methods than XML 1.0. What happens when XML  
2.0 arrives? What if someone wants to define an RFC for Enamel  
serialization of Atom?

> Does this proposal have any affect on implementations or conformance?

I think it reflects the current state of affairs, because Atom is almost  
solely defined in syntax and not in an abstract model. I don't think the  
syntax definition rules out other serializations than XML, though.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 2 Jul 2004 13:47:16 -0400

On Fri, 02 Jul 2004 19:12:28 +0200, Asbjørn Ulsberg
<[email-masked]> wrote:
> disallowing other serializatin methods than XML 1.0. 

You gain interoperability.

> What happens when XML 2.0 arrives? 

You don't use it with Atom until a follow-up
RFC obsoletes this one.

> What if someone wants to define an RFC for Enamel
> serialization of Atom?

Then write an RFC for it, but don't 
use the application/atom+xml media-type.

    -joe

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 02 Jul 2004 22:33:54 +0200

On Fri, 2 Jul 2004 13:47:16 -0400, Joe Gregorio <[email-masked]>  
wrote:

>> I can't see what we gain from disallowing other serializatin
>> methods than XML 1.0.
>

True.

> You don't use it with Atom until a follow-up RFC obsoletes this
> one.

Right.

> Then write an RFC for it, but don't use the
> application/atom+xml media-type.

That wouldn't be the idea, either. If the intent of the Pace is to  
disallow other formats than XML to be transmitted with the mime type  
'application/atom+xml', I think requiring no infoset and no other  
serializations is to shoot flies with artillery.

Can't we just say somewhere in the specification that for  
'application/atom+xml' no other format than XML (which I think is very  
strongly implied in the MIME type, anyway) should be served? If someone  
wants to transmit Atom as Enamel, they should create a MIME type for it,  
e.g. 'application/atom+nml'.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Jul 2004 22:09:26 -0700

How about:

"Atom's data model is described in terms of the XML Information Set 
[ref] and serialised as XML 1.0 [ref]."

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 03 Jul 2004 12:09:33 +0100

> [ref] and serialised as XML 1.0 [ref]."

+1, that's very clear.

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Sat, 03 Jul 2004 07:29:09 -0700

> [ref] and serialised as XML 1.0 [ref]."

I can live with that, I'd prefer something like

"Atom data is interchanged in the form of XML 1.0 documents [ref].  In 
this specification, the XML Information Set [ref] is used to specify 
the allowable syntax of these documents."

Reasons being
(a) I don't have any concern if someone, in the bowels of their CMS, 
serializes Atom data as a bunch of relational tables or whatever; the 
important thing whenever Atom data is *interchanged*, it's in XML 1.0 
docs.  I guarantee there are going to be language lawyers who are going 
to flame away at some poor vendor who uses an efficient non-XML 
datastore for Atom in a totally harmless way.
(b) It seems to me the *real* usefulness of the Infoset is to provide a 
handy way to specify which elements and attributes you're going to use, 
and which order they appear in.

   -Tim

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 3 Jul 2004 09:11:54 -0700

At 7:29 AM -0700 7/3/04, Tim Bray wrote:
>"Atom data is interchanged in the form of XML 1.0 documents [ref]. 
>In this specification, the XML Information Set [ref] is used to 
>specify the allowable syntax of these documents."

+1, because...

>I guarantee there are going to be language lawyers who are going to 
>flame away at some poor vendor who uses an efficient non-XML 

This has happened before in other contexts. Vendors say the dumbest 
things about how bad their competitors are, knowing that the press 
prefers conflict to boredom.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Joe Gregorio <[email-masked]>
Date: Sat, 3 Jul 2004 13:44:10 -0400

> the allowable syntax of these documents."

+1

   -joe

---

From: Michael Champion <[email-masked]>
Date: Sat, 3 Jul 2004 14:03:06 -0400

> the allowable syntax of these documents."

That doesn't sound quite right ... the Infoset specifies the allowable 
logical structure, not the "syntax," no?
> docs.

What about those who expose Atom feeds via XQuery?  Isn't this 
"interchange" via the XQuery data model rather than the XML 
serialization?  (Granted that the Infoset is not the same as the XQuery 
data model, but I am assuming that we are talking about the "Infoset" 
as any abstract XML data model  , and XQuery's data model is one of 
them ....)

> (b) It seems to me the *real* usefulness of the Infoset is to provide 
> a handy way to specify which elements and attributes you're going to 
> use, and which order they appear in.
>

Well, again if we are talking about the Infoset as an abstract data 
model, the XPath data model is an "infoset" which will have a very 
concrete use for Atom users who wish to transform it to HTML or some 
other XML structure.

  I like Mark Nottingham's formulation: "Atom's data model is described 
in terms of the XML Information Set [ref] and serialised as XML 1.0 
[ref]. " because it emphasizes that Atom is both an abstract model that 
can be queried and manipulated with XPath, XSLT, and XQuery; and a 
concrete XML syntax that can be exchanged over a wire and 
parsed/manipulated with an immense number of standardized tools.

---

From: Tim Bray <[email-masked]>
Date: Sat, 03 Jul 2004 11:52:08 -0700

> logical structure, not the "syntax," no?

When Atom is interchanged, it is interchanged as XML documents.   What 
the infoset specifies is which elements and attributes are used and in 
which order.  Whether you want to call that a "logical structure" or a 
"syntax" doesn't seem that big a deal... but I lean in favor of syntax 
because interoperation, in particular across a network, takes place at 
the level of syntax.

> serialization?  (Granted that the Infoset is not the same as the 
> XQuery data model, but I am assuming that we are talking about the 
> "Infoset" as any abstract XML data model  , and XQuery's data model is 
> one of them ....)

If someone wants to support querying Atom via XQuery or SQL or any 
other query facility, that's fine with me, and the spec shouldn't get 
in the way.  I don't think the proposed language does.  And when we say 
say Infoset, we don't mean "any abstract data model", we mean Infoset.

> [ref]. " because it emphasizes that Atom is both an abstract model 
> that can be queried and manipulated with XPath, XSLT, and XQuery; and 
> a concrete XML syntax that can be exchanged over a wire and 

The reason the specification exists is to support programmers in 
building software which interoperates across the network.  All they can 
be sure of is that they will get messages which are XML 1.0 documents 
and whose syntax is constrained in a way that's conveniently described 
using the Infoset.  The logical model they choose to construct inside 
their software to deal with this is none of our concern, and if it 
looks totally unlike the XML Infoset, that's fine and we shouldn't give 
anyone help in claiming that it isn't.  -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 03 Jul 2004 21:12:12 +0200

>> [ref] and serialised as XML 1.0 [ref]."

I agree. Does this one sentence need its own pace? I think not. But if it  
does, I have no problems with creating it.

---

From: Michael Champion <[email-masked]>
Date: Sat, 3 Jul 2004 16:56:02 -0400

On Jul 3, 2004, at 2:52 PM, Tim Bray wrote:

>
>  Whether you want to call that a "logical structure" or a "syntax" 
> doesn't seem that big a deal... but I lean in favor of syntax because 
> interoperation, in particular across a network, takes place at the 
> level of syntax.

OK, no big deal, we're talking about the same thing I guess -- the 
allowed elements and attributes, and where they can appear.

> building software which interoperates across the network.  All they 
> can be sure of is that they will get messages which are XML 1.0 
> documents and whose syntax is constrained in a way that's conveniently 
> described using the Infoset.  The logical model they choose to 
> construct inside their software to deal with this is none of our 
> concern, and if it looks totally unlike the XML Infoset, that's fine 
> and we shouldn't give anyone help in claiming that it isn't.  -Tim
>

Well, as far as I'm concerned someone querying an XQuery-enabled DBMS 
for Atom entries is "building software which interoperates across the 
network" and I (albeit with a certain amount of day-job bias) think of 
this as a reasonable use case for Atom.  I don't want to belabor the 
point because there is a close enogh correspondence between XML "bits 
on the wire" and the data model of XPath/XQuery and I can't imagine how 
your proposed language in the Atom spec would get in the way of that in 
the real world.  Still, as a way of aligning Atom with the range of XML 
specs that are in wide use, especially XPath/XSLT/XQuery, I would 
prefer a neutral statement such as Mark proposed rather than an 
explicit statement that Atom is *only* a bits on the wire syntax.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 4 Jul 2004 09:11:46 -0700

> allowed elements and attributes, and where they can appear.

I think this is a big deal, actually; "logical structure" and "syntax" 
imply two very different things. The former implies a data model, the 
latter implies a sequence of bytes. They're two very different ideas of 
what "Atom" is.

>> documents and whose syntax is constrained in a way that's 
>> conveniently described using the Infoset.  The logical model they 
>> choose to construct inside their software to deal with this is none 
>> of our concern, and if it looks totally unlike the XML Infoset, 
>> that's fine and we shouldn't give anyone help in claiming that it 
>> isn't.  -Tim

Exactly. We only need one model to describe Atom with (and the Infoset 
will do just fine); we don't need to either explicitly allow or 
disallow other models; it's implicit that people can use other models 
within their own implementations.

It's also possible that people in the future might want to come up with 
a different serialisation of the model we describe Atom with;  however, 
they shouldn't call the result "Atom" without some kind of 
clarification (e.g., a different media type).

What we need to be really, really crisp about here is whether "Atom" 
refers to the data model that we describe in the spec, or the sequence 
of bits when we serialise that on the wire. If we go with the former, 
people will be able to call anything that conforms to that model 
"Atom," no matter how it's serialised. If we go with the latter, people 
will only be able to call a very particular serialisation of the data 
model "Atom".

In other words, we can bind the name "Atom" with the concepts people 
have in their head -- feeds, entries and so forth -- or with can bind 
it to the characters on the wire -- "<feed>", "<entry>" and so forth 
(Namespaces make this more complex in reality, but you get the idea). 
It's Infoset-level vs. MIME entity-level.

On balance, I can go with either of these approaches, as long as we 
make a clear distinction. I don't want people to be having this 
disagreement after we have an RFC.

I personally lean towards the former, because my general experience has 
been that extensibility is useful in specifications; it improves their 
chances of being relevant in the long term. If a truly better 
serialisation of the Infoset comes out (whether it's XML 1.5, 3.0 or 
binary XML 1.0) and gets serious traction, it would be a shame if we 
had to call Atom something different to take advantage of it 
(obviously, it'd need a new media type, for interop). Granted, I'm not 
at all convinced that it's possible to offer enough value to get that 
traction.

The latter approach cuts off alternate serialisations at the knees; you 
couldn't even refer to them in prose as "Atom", it would have to be 
something like "Atom/XML1.1". I'm not against this, but wonder if it's 
really necessary; the market will build its own profile of what "Atom" 
means, no matter what the underlying technology is.

In any case, we need close on this; can we get a reading from folks on 
whether they want Atom to mean:
   a) An abstract data model
   b) A particular arrangement of bits

As stated, I'm OK with either.

Cheers,

---

From: Tim Bray <[email-masked]>
Date: Sun, 04 Jul 2004 09:52:36 -0700

>   b) A particular arrangement of bits

(b), because experience has taught us that interoperation on the basis 
of syntax is do-able (not easy, do-able), while interaction on the 
basis of data model is insanely difficult in the general case in 
heterogeneous networked applications.  I think we have to be all about 
interoperability first, last, and always. -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 4 Jul 2004 10:13:43 -0700

On Jul 4, 2004, at 9:52 AM, Tim Bray wrote:

>> In any case, we need close on this; can we get a reading from folks 
>> on whether they want Atom to mean:

Of course we have to think about interoperability, but that isn't the 
question at hand; Atom will be specified in terms of the same 
constructs -- i.e., we'll interoperate based upon the Infoset -- no 
matter what the outcome of this decision.

What does "interoperation on the basis of syntax" mean? No matter how 
we specify Atom, it will involve an abstraction, even if that is a 
sequence of characters (which would be massively inefficient; I 
personally don't want to start writing "a '<' character followed by 
either...").

The question at hand is what abstraction "Atom" refers to. If we 
constrain it to a particular serialisation of the Infoset, that's fine, 
but I don't think that the statement "Atom is XML 1.0" buys much in 
terms of interoperability; MIME has enough flexibility to accommodate 
different serialisations of an abstraction in an interoperable fashion.

---

From: Michael Champion <[email-masked]>
Date: Sun, 4 Jul 2004 13:35:09 -0400

On Jul 4, 2004, at 12:52 PM, Tim Bray wrote:

>  I think we have to be all about interoperability first, last, and 
> always. -Tim
>
>
Absolutely, that's the whole reason for Atom's existence.  I agree with 
Mark that Atom should be unambiguous on which definition it uses, and 
don't think that it is worth a long digression over which is chosen, 
but
  I just don't accept the premise that interoperability can only be 
guaranteed at the "arrangement of bits on the wire" level.  That's 
certainly not the experience of the DBMS world where interoperability 
(to the extent that it is possible at all due to business issues such 
as who supports which definitions of SQL) is indeed at the level of the 
SQL language and ODBC/JDBC/ADO/JDO/etc. APIs.  The reasonably decent 
interoperability of the numerous variants of HTML and RSS could be 
interpreted either way ("the glass is half empty" because 
interoperability is partial and tedious for developers, or "the glass 
is half full" because most end users don't have to care). Likewise, 
this mailing list seems to have spent the bulk of its bandwidth 
discussing in excruciating detail the myriad ways in which the XML and 
internet standards do not really and truly define the arrangement of 
bits on the wire in a way that real people can use with confidence 
today.

Given the likelihood that Atom will have to coexist with specs such as 
SOAP and XQuery as well as with syntax-level specs such as XML  it is 
at least arguable that basing the definition on an abstract data model 
will be both easier for this group to actually complete and more useful 
for code developers.  Likewise, XML itself  is evolving -- XML 1.1 
certainly threw a monkey wrench into SOAP 1.2; I don't have an opinion 
whether that would have been more or less damaging had SOAP been based 
on bits on the wire rather than the Infoset, but it seems worth 
analyzing here.  Other changes, such as the possibility of a de facto 
standard (or two, or three) performance-optimized  XML serialization 
need to have their impacts on Atom analyzed.  Can you really just say 
"don't do that" and expect the world to agree?  Maybe, but if you 
define Atom at the information model level then the question just 
doesn't come up.

Again, I don't have a really strong opinion that defining Atom as an 
abstract data model is the best approach, but I do think that some 
further discussion is necessary -- it's not nearly as cut and dried as 
Tim's statement  that "experience teaches us" that interoperation at 
the syntax level is more easily achieveable implies, IMHO.  At a 
minimum, I suggest that you satisfy yourselves that the syntax-level 
definition solves more problems than it creates under a plausible set 
of use cases, including:
- XQuery access of Atom syndicated in a DBMS
- Atom transported within a SOAP envelope
- A possible future with one or more "efficient" serializations of the 
Infoset being widely supported.

---

From: Graham <[email-masked]>
Date: Sun, 4 Jul 2004 13:55:26 -0400

On 4 Jul 2004, at 1:13 pm, Mark Nottingham wrote:

> constrain it to a particular serialisation of the Infoset, that's 
> fine, but I don't think that the statement "Atom is XML 1.0" buys much 
> in terms of interoperability; MIME has enough flexibility to 
> accommodate different serialisations of an abstraction in an 
> interoperable fashion.

Yes, but software doesn't. My experience is that people trying to be 
clever by do it by jamming a crowbar in any gap in the spec they spot. 
If the spec allows for alternate serializations, no matter what 
language you use to discourage them, some idiot somewhere is going 
shove an ASN.1 or soemthing feed online and then complain that all (or 
certain) "Atom-compatible" aggregators are broken. They might even 
persuade a couple of developers to support it, which means we'll all 
have to. I think the spec needs to be completely locked down on this 
aspect if we're to retain control of what happens out in the wild.

Graham

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 4 Jul 2004 13:57:31 -0700

OK. Are we going to take the same approach to extensibility of Atom 
itself? For example, are we going to disallow Atom feeds from being 
extended in such a way that current-generation aggregators can't fully 
understand them, or perhaps don't interoperate with them well?

This is perhaps the other facet of the question -- is "Atom" a strict 
profile of what we're doing (e.g. MUST have a title, MUST NOT have...) 
or is it just a generic container that different applications can 
extend?

In other words, is "Atom" a building block that can be used for a 
variety of tasks, or is a purpose-specific profile that requires 
certain things and has more limited extensibility?

Cheers,

P.S. I'm not pushing back on your answer, Graham -- I think you make an 
excellent point. IME, most efforts go through a crisis of identity, 
where some level of navel-gazing of the "what does 'is' mean?" sort is 
done. Doing so gets everybody on the same page, and is generally 
productive, as long as it doesn't turn into a rat-hole. It's good that 
we're at that stage so early in the process; getting around to it in 
the latter stages can be disastrous...

On Jul 4, 2004, at 10:55 AM, Graham wrote:

>> fine, but I don't think that the statement "Atom is XML 1.0" buys 
>> much in terms of interoperability; MIME has enough flexibility to

---

From: Danny Ayers <[email-masked]>
Date: Sun, 04 Jul 2004 23:13:02 +0200

>>   b) A particular arrangement of bits

This is a misleading contrast.  Neither model without syntax or syntax 
without model offer interop.

> interoperability first, last, and always. -Tim

Interoperation in what sense? Without anything shared beyond syntax, 
there can be no communication. Bits over the wire are still bits, 
nothing more.

On the other hand, we aren't looking for interaction on the basis of a 
data model *in the general case*, just within the scope of the 
syndication model. This is not insanely difficult, just fairly hard.

Fact is, we need model (however informal) and at least one syntax for 
interop. I'd push the proportions more towards (a formal) model, but 
that's just my personal preference.

Cheers,
Danny.

-- 

Raw
http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Sun, 4 Jul 2004 17:37:21 -0400

> understand them, or perhaps don't interoperate with them well?

I think this was what I was getting at with my comments about <content 
src="">. The best approach to extensibility to me would be 
multi-faceted-ness - ie Different kinds of applications would have 
there own part of Atom, and can be targeted specifically and 
separately. Overloading of specific elements means they change meaning 
in different contexts, and a non-target-audience app has problems, 
which threatens manageability and transparency of the format.

Back to the topic, I think the best approach, if we're going to allow 
alternate serializations to be called Atom, is to have all endpoints 
able to provide and consume XML 1.0, and there to be a standard way to 
get to it.

Graham Parks

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 4 Jul 2004 14:48:32 -0700

Interesting. If I read you correctly, this would mean that we'd say 
that Atom-the-format would be a data model that allows multiple 
serialisations, but only defines one, XML 1.0. Meanwhile 
Atom-the-protocol would require support for the defined XML 1.0 
serialisation, but would allow negotiation of other format 
serialisations when they're supported.

Correct? If so, +1 from me to the approach. It does mean we need to be 
careful about defining conformance of endpoints in the protocol, but I 
think that's a good thing.

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 4 Jul 2004 18:00:30 -0400

Mark Nottingham wrote:
> It's also possible that people in the future might want to come
> up with a different serialisation of the model we describe Atom
> with;  however, they shouldn't call the result "Atom" without some
> kind of clarification (e.g., a different media type).
	How different must the media type be in order to be "acceptable" to
the Atom community?
	As is well known from previous discussions of this topic, I would
very much like to be able to use an alternative serialization in a number of
high volume applications for Atom. One very good looking alternative to XML
would be the "Fast Infoset"[1] that Sun is sponsoring through the ITU/ISO
standardization process. Fast Infoset is explicitly designed to encode the
XML Infoset in a compact and efficiently parsed format while ensuring that
one can build interfaces via SAX or even a version of GENX whose behavior is
largely indistinguishable from implementations that are written over
text-based XML. Once Fast Infoset is finished with its rounds through the
standardization process, I'd like to have
	application/atom+fastinfoset
as an alternative to:
	application/atom+xml

	This is a distinct media type but still contains the string
"atom"... Would that be acceptable?

		bob wyman

[1] http://java.sun.com/developer/technicalArticles/xml/fastinfoset/

---

From: DJWS <[email-masked]>
Date: Mon, 05 Jul 2004 01:32:17 +0200

At 00:00 05/07/04, Bob Wyman wrote:
>Fast Infoset is explicitly designed to encode the XML Infoset in a compact 
>and efficiently parsed format while ensuring that one can build interfaces 
>via SAX or even a version of GENX whose behavior is largely 
>indistinguishable from implementations that are written over text-based 
>XML. Once Fast Infoset is finished with its rounds through the 
>standardization process, I'd like to have application/atom+fastinfoset as 
>an alternative to: application/atom+xml

Could it be not supported in using ASN.1. I understand that Fast Infoset is 
only a Java version of ASN.1 support ? Are there no "C" existing tools 
which could be used with ATOM now ? (My main initial interest in ATOM is 
that support).
Thank you.
Jefsey Morfin

>This is a distinct media type but still contains the string "atom"... 
>Would that be acceptable?
>                 bob wyman
>

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 4 Jul 2004 21:14:15 -0400

Mark Nottingham wrote:
> If I read you correctly, this would mean that we'd say 
	+1 (It would be *excellent* if this were the case!)

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 4 Jul 2004 21:28:14 -0400

DJWS wrote:
> I understand that Fast Infoset is only a Java version of ASN.1 support ?

	There is absolutely no relationship between Java and Fast Infoset. 

	Fast Infoset is defined using an ASN.1 schema and uses ASN.1 PER as
an encoding format. Thus, any code that can deal with PER can read and write
Fast Infoset. However, I'm confident that most users of Fast Infoset won't
know or even care that an ASN.1 defined binary encoding is being used. This
is because Fast Infoset involves only one very simple, fixed schema for the
infoset and only uses a small portion of the full power of PER. Thus, my
expectation is that it will be very easy to produce open-source modules that
work with Fast Infoset. The situation will be the same as exists today with
libaries that read and write X.500 certificates (which are encoded using
binary ASN.1). There are many code libraries that encode and decode X.500
certificates with great ease and facility but are not capable of dealing
with any other binary data.
	I expect that since Sun is a strong supporter of Fast Infoset, they
will probably lead in developing Java-based tools to work with it. However,
this is not because of any linkage between Fast Infoset and Java, rather, it
is just because Sun is a strong supporter of both Java and Fast Infoset.
We'll have to wait for the Fast Infoset standard to get finished and in the
field before we know what the actual support will look like. I think,
however, that you should assume that good C support will be available.

		bob wyman

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 4 Jul 2004 19:04:18 -0700 (PDT)

--- Bob Wyman <[email-masked]> wrote:
> field before we know what the actual support will
> look like. 

Which standards body has Fast Infoset been submitted
to? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 4 Jul 2004 20:57:15 -0700

Fast Infoset is being standardised by a joint committee of ISO -- the 
mother of all standards organisations -- and ITU.
   http://www.itu.int/ITU-T/asn1/workprogram.html

This doesn't mean that it will be successful, adopted by the market, or 
the right thing to do technically, but you certainly can't say that it 
isn't a "real standard"; arguably, it's more real than XML, HTTP and 
all the rest, as ISO is a de jure standards organisation, unlike the 
W3C and IETF, which are both "mere" consortia.

That also doesn't mean that it's what most people would call an "open" 
process, hence the paucity of information available online.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 5 Jul 2004 12:36:38 -0400

Dare Obasanjo wrote:
>Which standards body has Fast Infoset been submitted to? 
	Fast Infoset[1] is the joint work of ISO/IEC-JTC1/SC6 [2] and
ITU-T/SG17[3,4]. Fast WebServices (aka: X.695)[5] is also a joint ISO/ITU
project.

		bob wyman

[1] http://java.sun.com/developer/technicalArticles/xml/fastinfoset/
[2] http://www.jtc1.org/: SC6 is the current home of X.400, X.500 and ASN.1
[3] http://www.itu.int/ITU-T/studygroups/com17/index.asp
[4] http://www.itu.int/ITU-T/asn1/
[5] http://java.sun.com/developer/technicalArticles/WebServices/fastWS/

---

From: Martin Duerst <[email-masked]>
Date: Mon, 05 Jul 2004 08:37:00 +0900

At 22:09 04/07/02 -0700, Mark Nottingham wrote:

>How about:
>
>"Atom's data model is described in terms of the XML Information Set [ref] 
>and serialised as XML 1.0 [ref]."

As long as this does not imply using the terms in the XML Information Set
spec (Element Information Item, Attribute Information Item,...), I'm fine
with this. Using these terms would make the spec longer and more tedious
to read at no real benefit.

Regards,   Martin.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 5 Jul 2004 16:06:42 -0700

That's the plan; the Notational Conventions state:

                 Atom is specified using the XML Infoset, but uses a 
shorthand
                 for common terms; the phrase "Information Item" is not 
used
                 when naming XML constructs.

Cheers,

---

From: Sam Ruby <[email-masked]>
Date: Tue, 06 Jul 2004 08:15:23 -0400

Tim Bray wrote:

> of syntax is do-able (not easy, do-able), while interaction on the basis 
> of data model is insanely difficult in the general case in heterogeneous 
> networked applications.  I think we have to be all about 

I don't quite see it as that black and white.

In particular, I see the following arrangements of bits as being 
indistinguishable:

    '>', '&gt;', '&#62;', and '&#x3e', '&#x3E'

There are a number of other questions which infosets answer.  For 
example, on elements which permit a number of attributes, are the order 
of attributes significant?  Is the amount of whitespace separating such 
attributes significant?

- Sam Ruby