Subject: Re: Created proposal: PaceProvideSchema

From: Randy Charles Morin <[email-masked]>
Date: Sun, 11 Jul 2004 18:37:17 -0700 (PDT)

Norman Walsh wrote:
>Uhm. So don't use XSD?

So, we shouldn't use the schema language that is most supported by vendors. Don't use the schema language language which Microsoft and Apache/IBM have created countless tools from. Let's start from scratch. Clean slate.
Thanks,
 
Randy
http://www.kbcafe.com

---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 11 Jul 2004 20:12:13 -0700

On Jul 11, 2004, at 6:37 PM, Randy Charles Morin wrote:

> So, we shouldn't use the schema language that is most supported by 
> vendors.
> Don't use the schema language language which Microsoft and 
> Apache/IBM have created countless tools from. Let's start from 
> scratch. Clean slate.

Sounds sensible to me. Seriously. Just because MSFT and IBM have thrown 
resources at it doesn't mean that it'll magically work, thanks to their 
pixie dust; both have made mistakes, of which there are numerous 
examples. I'm not just picking on them, of course, but they were the 
only vendors you mention.

Consider this - WSDL isn't specified in terms of XML Schema; it defines 
a "component model." Neither does SOAP; that's right, the Schema isn't 
normative, just informational.

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

---

From: James M Snell <[email-masked]>
Date: Sun, 11 Jul 2004 21:56:49 -0600

IMHO, like WSDL and SOAP, Atom should also provide an *informational* XML 
Schema.  It may be something put together "unofficially" by those of us 
who care about such things, but something should be made available.

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

Mark Nottingham <[email-masked]> 
Sent by: [email-masked]
07/11/2004 08:12 PM

To
[email-masked]
cc
Atomlist <[email-masked]>
Subject
Re: Created proposal: PaceProvideSchema

---

From: Randy Charles Morin <[email-masked]>
Date: Sun, 11 Jul 2004 21:09:33 -0700 (PDT)

Don't worry James, I will always make my XML Schema available to those that case. Regardless of whether Atom has an official XSD, I will always have an unofficial one.
http://www.kbcafe.com/rss/?guid=20040710135750
 
I use to write Java for Solaris. I use to write Java for Weblogic. I guess I've been told that they are not going to support standards enough times. Now I write for .NET and Apache Axis. They actually support XSD better. 
Thanks IBM and M$FT,
 
Randy
http://www.kbcafe.com

James M Snell <[email-masked]> wrote:

IMHO, like WSDL and SOAP, Atom should also provide an *informational* XML Schema.  It may be something put together "unofficially" by those of us who care about such things, but something should be made available. 

- James M Snell
 [email-masked]
 http://www.ibm.com
 (877) 511-5082 / Office
 930-1979 / Tie Line 

Mark Nottingham <[email-masked]> 
Sent by: [email-masked] 
07/11/2004 08:12 PM 
To
[email-masked] cc
Atomlist <[email-masked]> Subject
Re: Created proposal: PaceProvideSchema

> ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s

---------------------------------
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!

---

From: Norman Walsh <[email-masked]>
Date: Mon, 12 Jul 2004 07:29:20 -0400

/ Randy Charles Morin <[email-masked]> was heard to say:
| Norman Walsh wrote:
|>Uhm. So don't use XSD?
|
| So, we shouldn't use the schema language that is most supported by
| vendors. Don't use the schema language language which Microsoft and
| Apache/IBM have created countless tools from. Let's start from
| scratch. Clean slate. Thanks,

I didn't propose a schema for the spec so that it would be easy to plug
into a data binding application and build a Java object graph of an
Atom feed. I didn't propose it so that an Atom feed could be decomposed
into a set of complex types for use in building an aggregator application.
I didn't proposed it for any of a number of reasons that would make XSD
the natural choice.

I proposed it in order to aid human comprehension. I think it should
simultaneously satisfy two criteria: conciseness and accuracy. For this
application, I think RELAX NG satisfies those two criteria better.

Actually, I proposed[1] that we provide both a RELAX NG grammar and an XSD
precisely so that we could avoid this sort of pissing contest.

Here's an XSD that approximates the RNC I posted the other day.

<?xml version="1.0" encoding="UTF-8"?>
<!-- -*- Relax NG -*- -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://purl.org/atom/ns#" xmlns:atom="http://purl.org/atom/ns#">
  <xs:import schemaLocation="local.xsd"/>
  <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd"/>
  <!-- Attribute definitions -->
  <xs:attributeGroup name="atomCommonAttributes">
    <xs:attribute ref="xml:base"/>
    <xs:attribute ref="xml:lang"/>
  </xs:attributeGroup>
  <xs:attributeGroup name="atomVersionAttribute">
    <xs:attribute name="version" use="required"/>
  </xs:attributeGroup>
  <!-- Common Atom Constructs -->
  <xs:complexType name="atomContentConstruct" mixed="true">
    <xs:group minOccurs="0" maxOccurs="unbounded" ref="atom:anyElement"/>
    <xs:attributeGroup ref="atom:atomCommonAttributes"/>
    <xs:attribute name="type"/>
    <xs:attribute name="mode">
      <xs:simpleType>
        <xs:restriction base="xs:token">
          <xs:enumeration value="xml"/>
          <xs:enumeration value="escaped"/>
          <xs:enumeration value="base64"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="atomPersonConstruct">
    <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:element ref="atom:name"/>
      <xs:element ref="atom:url"/>
      <xs:element ref="atom:email"/>
    </xs:choice>
    <xs:attributeGroup ref="atom:atomCommonAttributes"/>
  </xs:complexType>
  <xs:element name="name" type="xs:string"/>
  <xs:element name="url" type="xs:string"/>
  <xs:element name="email" type="xs:string"/>
  <xs:complexType name="atomDateConstruct">
    <xs:simpleContent>
      <xs:extension base="xs:dateTime">
        <xs:attributeGroup ref="atom:atomCommonAttributes"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:attributeGroup name="atomLinkConstruct">
    <xs:attributeGroup ref="atom:atomCommonAttributes"/>
    <xs:attribute name="rel" use="required">
      <xs:simpleType>
        <xs:restriction base="xs:token">
          <xs:enumeration value="alternate"/>
          <xs:enumeration value="start"/>
          <xs:enumeration value="next"/>
          <xs:enumeration value="prev"/>
          <xs:enumeration value="service.edit"/>
          <xs:enumeration value="service.post"/>
          <xs:enumeration value="service.feed"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="type" use="required"/>
    <xs:attribute name="href" use="required"/>
    <xs:attribute name="hreflang"/>
    <xs:attribute name="title"/>
  </xs:attributeGroup>
  <!--
    atom:feed
    TODO: Test for multiple atom:link/@rel='alternate' with the same @type
    The following tests are simple to do, but my validator is giving me trouble.
    TODO: Debug and add them back
          Test for at least one atom:link/@rel='alternate'
          Test for atom:author or all atom:entry have atom:author
  -->
  <xs:element name="feed">
    <xs:complexType>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="atom:title"/>
        <xs:element ref="atom:link"/>
        <xs:element ref="atom:author"/>
        <xs:element ref="atom:contributor"/>
        <xs:element ref="atom:tagline"/>
        <xs:element ref="atom:id"/>
        <xs:element ref="atom:generator"/>
        <xs:element ref="atom:copyright"/>
        <xs:element ref="atom:info"/>
        <xs:element ref="atom:modified"/>
        <xs:element ref="atom:entry"/>
        <xs:group ref="atom:anyElement"/>
      </xs:choice>
      <xs:attributeGroup ref="atom:atomCommonAttributes"/>
      <xs:attributeGroup ref="atom:atomVersionAttribute"/>
    </xs:complexType>
  </xs:element>
  <!-- atom:title -->
  <xs:element name="title" type="atom:atomContentConstruct"/>
  <!-- atom:link -->
  <xs:element name="link">
    <xs:complexType>
      <xs:attributeGroup ref="atom:atomLinkConstruct"/>
    </xs:complexType>
  </xs:element>
  <!-- atom:author -->
  <xs:element name="author" type="atom:atomPersonConstruct"/>
  <!-- atom:contributor -->
  <xs:element name="contributor" type="atom:atomPersonConstruct"/>
  <!-- atom:tagline -->
  <xs:element name="tagline" type="atom:atomContentConstruct"/>
  <!-- atom:id -->
  <xs:element name="id" type="xs:string"/>
  <!-- atom:generator -->
  <xs:element name="generator">
    <xs:complexType mixed="true">
      <xs:attributeGroup ref="atom:atomCommonAttributes"/>
      <xs:attribute name="version"/>
      <xs:attribute name="url"/>
    </xs:complexType>
  </xs:element>
  <!-- atom:copyright -->
  <xs:element name="copyright" type="atom:atomContentConstruct"/>
  <!-- atom:info -->
  <xs:element name="info" type="atom:atomContentConstruct"/>
  <!--
    atom:modified
    TODO: Test for a timezone that SHOULD be UTC
  -->
  <xs:element name="modified" type="atom:atomDateConstruct"/>
  <!--
    atom:entry
    TODO: Test for multiple atom:link @rel='alternate' with the same @type
  -->
  <xs:element name="entry">
    <xs:complexType>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="atom:title"/>
        <xs:element ref="atom:link"/>
        <xs:element ref="atom:author"/>
        <xs:element ref="atom:contributor"/>
        <xs:element ref="atom:id"/>
        <xs:element ref="atom:modified"/>
        <xs:element ref="atom:issued"/>
        <xs:element ref="atom:created"/>
        <xs:element ref="atom:summary"/>
        <xs:element ref="atom:content"/>
        <xs:element ref="atom:copyright"/>
        <xs:group ref="atom:anyElement"/>
      </xs:choice>
      <xs:attributeGroup ref="atom:atomCommonAttributes"/>
      <xs:attribute name="version"/>
    </xs:complexType>
  </xs:element>
  <!-- atom:issued -->
  <xs:element name="issued" type="atom:atomDateConstruct"/>
  <!--
    atom:created
    TODO: Test for a timezone that SHOULD be UTC
  -->
  <xs:element name="created" type="atom:atomDateConstruct"/>
  <!-- atom:summary -->
  <xs:element name="summary" type="atom:atomContentConstruct"/>
  <!-- atom:content -->
  <xs:element name="content" type="atom:atomContentConstruct"/>
  <!-- Low-level simple types -->
  <!-- TODO: can anything more specific be said about these types? -->
  <!-- Extensibility -->
  <xs:group name="anyForeignElement">
    <xs:sequence>
      <xs:any namespace="##other" processContents="skip"/>
    </xs:sequence>
  </xs:group>
  <xs:attributeGroup name="anyForeignAttribute">
    <xs:anyAttribute processContents="skip"/>
  </xs:attributeGroup>
  <xs:group name="anyElement">
    <xs:sequence>
      <xs:group ref="local"/>
    </xs:sequence>
  </xs:group>
</xs:schema>
<!-- EOF -->

                                        Be seeing you,
                                          norm

[1] http://www.imc.org/atom-syntax/mail-archive/msg06494.html
-- 
Norman Walsh <[email-masked]> | I have animal magnetism. When I go
http://nwalsh.com/            | outside, squirrels stick to my clothes.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 12 Jul 2004 14:32:51 -0700 (PDT)

> normative, just informational.

Considering that at one time there was a claim that
Atom would support SOAP wouldn't it then be useful for
there to be a normative WSDL for Atom (which means
there will have to be a normative element declaration
for atom:entry at least)? The alternative would be for
every vendor that supports the Atom API to cook up
their own schemas for atom:entry which could lead to
incompatibility. 

=====
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 is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 14:43:29 -0700

> their own schemas for atom:entry which could lead to

It doesn't have to be normative to be included in the spec, and for 
people to use it.

---

From: Randy Charles Morin <[email-masked]>
Date: Mon, 12 Jul 2004 14:48:57 -0700 (PDT)

Actually, I would like more clarity here. Tim said that Atom will be SOAP friendly [1], but there's a proposal to remove the SOAP from Atom [2]. Can this be settled? Can I ask the IETF working group to do a straw poll and/or decide either way.
Thanks,
 
Randy
 
[1] - http://www.tbray.org/ongoing/When/200x/2004/06/10/AtomIETFYes
[2] - http://www.intertwingly.net/wiki/pie/PacePutDelete

Dare Obasanjo <[email-masked]> wrote:

=====

---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!

---

From: Tim Bray <[email-masked]>
Date: Mon, 12 Jul 2004 15:21:15 -0700

On Jul 12, 2004, at 2:48 PM, Randy Charles Morin wrote:

> Actually, I would like more clarity here. Tim said that Atom will be 
> SOAP friendly [1], but there's a proposal to remove the SOAP from Atom 
> [2]. Can this be settled? Can I ask the IETF working group to do a 
> straw poll and/or decide either way.

No, but we'll make sure that issue is in our input queue. (Through 
which we're making good progress, thank you everyone!) Is there a Pace 
for it? [checks]  I don't think so.  Clearly PacePutDelete and 
PlaceWsdl are related.  Do we need a Unified Pace for all these related 
issues?  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Mon, 12 Jul 2004 18:24:15 -0400

On 7/12/04 5:32 PM, "Dare Obasanjo" <[email-masked]> wrote:

> Atom would support SOAP

SOAP support is in the current protocol draft (Appendix A).

> wouldn't it then be useful for
> for atom:entry at least)?

Given the introspection debates we've been having, I think a normative WSDL
for the protocol is worth considering.

Unfortunately, it appears the unfinished SOAP 1.2 and WSDL 1.2/2.0 bindings
working draft[1] would be a better fit for Atom, since it defines an HTTP
binding. 

Problems:
* only defines GET/POST, not sure if it allows others
* all endpoints must be on the same host, not sure why that is

Dave Orchard has written a WSDL 2.0 file for Atom 0.3:
http://www.pacificspirit.com/blog/2004/07/05/atom_03_wsdl_20

Robert Sayre

[1] http://www.w3.org/TR/wsdl12-bindings/#_http

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 12 Jul 2004 15:44:51 -0700

>It doesn't have to be normative to be included in the spec, and for 

+1 and +1

--Paul Hoffman, Director
--Internet Mail Consortium