Subject: Fwd: Management Item: Request for ATOM Link Relation [IANA #209057]

From: Lisa Dusseault <[email-masked]>
Date: Mon, 2 Feb 2009 11:05:23 -0800

This request for registration of the "schema" link relation will officially
come up at the Feb 12 IESG Telechat, where the IESG may approve the
registration without further documentation.  Comments welcome.

Thx,
Lisa

---------- Forwarded message ----------
From:     Richard Salz <[email-masked]>
Download (untitled) / with headers
text/plain 1.3k
I am writing to request a new Atom link relation, "schema" Publication of
the request is here:
http://www.ibm.com/developerworks/blogs/page/soma?entry=a_schema_link_for_at
om

The form follows. Thank you.

/r$

Attribute Value
schema
Description
This link type points to the schema used to define the content of
other elements in an "atom:entry" document. The "for" attribute is used to
identify the QName of the direct child of the "atom:entry" element that
the link is intended for.

Multiple links with the same ³for³ value SHOULD have different ³type²
values; processors are allowed to choose the schema language they best
support.

This link can appear in an "atom:feed" document where it specifies the
default for all feed elements. It can also appear within an "atom:entry"
element. Links in an entry override any links in a feed that have the same
"type" and "for" values.
Expected display characteristics
Generally, this link is not intended for display, although the "type"
attribute would control the display characteristics. This link is intended
for automated use.
Security considerations
As with any other link.
--
Visiting Member, IBM Academy
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/

---

From: Richard Salz <[email-masked]>
Date: Mon, 2 Feb 2009 14:34:57 -0500

I updated the link; I forgot to publish a correction.  The "schema" link 
relation is for items within the "atom:content" element, not the 
"atom:entry" document.

Sorry for any confusion.
        /r$

[email-masked] wrote on 02/02/2009 02:05:23 PM:

> This request for registration of the "schema" link relation will 
> officially come up at the Feb 12 IESG Telechat, where the IESG may 
> approve the registration without further documentation.  Comments 
welcome.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Feb 2009 20:36:28 +0100

> the link is intended for.

There is no "for" attribute in RFC 4287. If this use case requires it, 
maybe a link relation isn't the best way to do it (instead an extension 
attribute?).

The QName can be avoided by using the "Clark notation" 
({namespace-uri}local-name).

> values; processors are allowed to choose the schema language they best

It seems that collides a bit with RFC 4287's definition of type:

"On the link element, the "type" attribute's value is an advisory media 
type: it is a hint about the type of the representation that is expected 
to be returned when the value of the href attribute is dereferenced." -- 
<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.7.3>

> ...

Best regards, Julian

---

From: Richard Salz <[email-masked]>
Date: Mon, 2 Feb 2009 15:14:52 -0500

> maybe a link relation isn't the best way to do it (instead an extension 

Can  you show me what you mean by extension attribute?  It might not be 
common, but adding attributes to link elements seems legal according to 
the RFC.

> ({namespace-uri}local-name).

Is there a common XSD datatype for this?  I agree that if that's the 
strongest argument I can come up with, then...  I don't care much one way 
or the other, whatever the group prefers.

> It seems that collides a bit with RFC 4287's definition of type:

I thought it was clearly in the spirit -- you can get whichever type of 
schema you want.  Can you be a bit more specific for me?

Thanks for the feedback!

        /r$

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Feb 2009 21:26:46 +0100

> common, but adding attributes to link elements seems legal according to 

I would assume that they'd need to be in a namespace different from the 
default namespace, otherwise we would have a potential collision with 
future revisions of RFC 4287.

> or the other, whatever the group prefers.

I personally do not have problems with QNames in attribute values (IMHO 
that ship has sailed); but I wouldn't be surprised if others disagree. 
In this case it could easily be avoided.

> schema you want.  Can you be a bit more specific for me?

The type is only a hint; thus a SHOULD-level requirement not to have 
multiple instances of the same type seems to conflict with the advisory 
nature of the attribute...

BR, Julian

---

From: Eric Scheid <[email-masked]>
Date: Tue, 03 Feb 2009 07:49:36 +1100

> This link type points to the schema used to define the content of an
> "atom:content" element of an "atom:entry" document. The "for" attribute is
> used to identify the QName of the direct child of the "atom:content" element
> that the link is intended for.

is @for in the undefined or null namespace?

'direct child' .. are you thinking there might be multiple direct children
of atom:content, like this:

    <link rel="schema" href="..." for="foo" />
    <link rel="schema" href="..." for="bar" />
    <atom:content type="application/xml+something">
        <foo:blarg>...</foo:blarg>
        <bar:blarg>...</bar:blarg>
    </atom:content>

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 03 Feb 2009 07:53:21 +1100

> <http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.7.3>

I disagree. I read that as saying there's the one schema resource which is
expressed in different formats.

e.

---

From: Richard Salz <[email-masked]>
Date: Mon, 2 Feb 2009 16:17:43 -0500

> is @for in the undefined or null namespace?

Yes, because there didn't seem to be a need to put it into its own 
namespace. I'd rather avoid the clutter, but if the WG wants a separate 
namespace that's fine with me.

>         <bar:blarg>...</bar:blarg>

Yes.
 
Although I'd pick "snl:floorwax" and "snl:desert-topping" as my examples. 
:)

        /r$

---

From: "James Holderness" <[email-masked]>
Date: Mon, 2 Feb 2009 21:56:50 -0000

>        <bar:blarg>...</bar:blarg>

Is that legal? In the processing model for XML media types, RFC4287 says 
"this would normally mean that the atom:content element would contain a 
single child element", which kind of implies that it might, under certain 
conditions, contain more than one. But I don't see how.

RFC3023 puts me to sleep, so I may have misunderstood something, but I got 
the impression that +xml media types were specifically reserved for actual 
XML documents (the whole point is a common processing model is it not?). And 
a well-formed XML document, by definition, has exactly one root element. So 
what am I missing?

Regards
James

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 2 Feb 2009 23:46:44 +0100

> a well-formed XML document, by definition, has exactly one root element. So

text/xml-external-parsed-entity and application/xml-external-parsed-entity

Compare the 'document' production [1] with the 'extParsedEnt' one [2]
in REC-xml.
[1] http://www.w3.org/TR/REC-xml/#NT-document
[2] http://www.w3.org/TR/REC-xml/#NT-extParsedEnt

(and note at the same time that text/xml-dtd and application/xml-dtd
and text/xml-dtd cannot be used within atom:content as their not
well-formed "parsed entities", despite being "XML media types" defined
in RFC3023, as called by RFC4287 in the processing model for
atom:content)

(also note that RFC3023 doesn't prohibit the use of +xml for external
parsed entities that are not documents)

-- 
Thomas Broyer

---

From: Eric Scheid <[email-masked]>
Date: Tue, 03 Feb 2009 10:01:48 +1100

On 3/2/09 8:56 AM, "James Holderness" <[email-masked]> wrote:

>>> that the link is intended for
>> 

I believe you are correct, especially for +xml media types. I'm hard pushed
to think of any other media types which are for xml snippets/streams and
thus not single-root documents. There is at least one example of an xml
document with a media type which isn't +xml (I don't remember exactl what it
is other than it living somewhere inside the vnd- tree) - even there it's a
single-root-node xml document iirc.

Rich, can you explain a bit more your thinking behind the 'direct child'
distinction?

Do you have examples in mind where two different schemas might apply to
atom:content?

    <link rel="schema" href="http://example.org/snl" for="snl" />
    <link rel="schema" href="http://example.org/foo" for="foo" />
    <link rel="schema" href="http://example.org/bar" for="bar" />
    <atom:content type="application/something+xml">
        <snl:haha>
            <foo:blarg>...</foo:blarg>
            <bar:yadda>...</bar:yadda>
        </snl:haha>
    </atom:content>

e.

---

From: Bill de hOra <[email-masked]>
Date: Mon, 02 Feb 2009 23:17:19 +0000

> the link is intended for.

-1 for QNames in content.

> values; processors are allowed to choose the schema language they best

Some questions:

- What are the types here?

- Which schema languages can validate Atom?

- What should happen when validation fails (eg in an AtomPub scenario)?

- What should an application do when seeing a type it does not recognize?

It's not clear what the validation target is - the entry, the content, ...?

Does the rel type requires a co-occurence constraint with @for?

My concern is that people are going to use this a la DTDs, which means 
breaking with mustIgnore and applications that worked yesterday not 
working today.

> This link is intended

If there is associate validation behaviour, can the type not be used to 
deny service?

Bill

---

From: "James Holderness" <[email-masked]>
Date: Tue, 3 Feb 2009 00:20:56 -0000

> [2] http://www.w3.org/TR/REC-xml/#NT-extParsedEnt

Ok, that makes sense. I definitely slept through that section. I slept 
through pretty much anything to do with "external" in the XML spec too.

> parsed entities that are not documents)

This is the bit that really confused me, since I thought I was awake then. I 
guess I was thrown by the 15 occurrences of the phrase "XML document" in 
section 7, when they really meant any old XML entity. I should have been 
paying closer attention.

Thanks for clearing that up.

Regards
James

---

From: Richard Salz <[email-masked]>
Date: Mon, 2 Feb 2009 22:07:58 -0500

>        <bar:blarg>...</bar:blarg>

This is close, the link/@for values would actually be "for='foo:blarg'" 
for example.

I went back to the RFC and re-read 4.1.3.1.  It appears that you are 
right, multiple top-level elements inside atom:content are not allowed. 
Rats.  But we still need link/@for for use at the feed level, where 
individual atom:entry/atom:content elements might have different types of 
content.  Does that make more sense?

(Original, the schema link was intended for content in an atom:feed 
document, but other discussion convinced our group that "content" belonged 
in atom:content.  When I made that change I didn't go back and carefully 
check this.  Sorry.)

        /r$

---

From: Richard Salz <[email-masked]>
Date: Mon, 2 Feb 2009 22:22:53 -0500

> -1 for QNames in content.

Yeah, I don't really disagree.  But I kinda dislike {uri}lname because it 
looks too much like XSLT's AVT :)

> - What are the types here?

The types of the schema language.
 
> - Which schema languages can validate Atom?

I dunno.  Much of it is probably done via code, as opposed to a schema 
language.  My interest here is in being able to describe, in a 
machine-readable way, the content of an atom:content element.
 
> - What should happen when validation fails (eg in an AtomPub scenario)?

Out of scope; a server MAY reject the post.
 
> - What should an application do when seeing a type it does not 
recognize?

Ignore it, and keep looking in hope of finding a schema language 
(link/@type) that it does understand.
 
> It's not clear what the validation target is - the entry, the content, 
...?

Sorry, I don't understand the question.
 
> Does the rel type requires a co-occurence constraint with @for?
 
Interesting question.  If the @type differs, then no (since a single @for 
target could be described by multiple schema language). If the @type and 
@for are the same at the feed and entry level, then no (since the 
semantics are the entry takes precedence. But is it required that the 
combination of @type and @for be unique at the same "level" (feed or 
entry)?  Not sure.
 
> breaking with mustIgnore and applications that worked yesterday not 

Right now the only way to define the content of an atom:content element is 
by out of band understanding. I don't see how making it possible to put 
that information in-line breaks anything.  What am I not getting?
 
> If there is associate validation behaviour, can the type not be used to 

Is this a question, or a preference?

        /r$

---

From: Eric Scheid <[email-masked]>
Date: Tue, 03 Feb 2009 16:04:44 +1100

> looks too much like XSLT's AVT :)

instead of QNames, how about something like this:

    <link rel="schema" x:schema="notQName" href="foo.xsd" type="text/xsd" />
    <link rel="schema" x:schema="notQName" href="foo.dtd" type="text/dtd" />
    <atom:content type="..." x:schema="notQName">
        <foo:blarg />
    </atom:content>

(obviously, I'm only guessing at the link@type values there)

e.

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Feb 2009 08:11:32 -0800

Rich,

I'm not yet convinced that the for attribute is necessary.  Presumably, 
the schema format itself will be capable of identifying which elements 
it defines, meaning that a schema-aware processor could identify which 
schema to apply with relative ease.  Further, since the atom:content 
element is only going to have a single top-level element, it would 
follow that within a single atom:entry element, there'd only ever be 
reason for a single schema link in the entry.  schema links at the feed 
level don't make a lot of sense to me since the schema link itself is 
part of the entry metadata. Lastly, schema links at the feed level imply 
some kind of inheritance model for atom:link elements (e.g. an entry 
would inherit the schema links of the parent feed). The challenge with 
this is that Atom does not define any such inheritance model for 
atom:link and experience has shown that inheritance is not necessarily a 
good thing.

My suggestions would be to drop the for attribute, limit the schema link 
to one instance per entry, and do not use schema links at the atom:feed 
level at all.

- James

---

From: Richard Salz <[email-masked]>
Date: Tue, 3 Feb 2009 11:42:05 -0500

Without a schema link at the feed level, how can a client know what the 
server is expecting to see?

Just as atom entries in a feed can be a mix of text, html, xhtml, why 
can't they be a mix of schema-defined entries?  The syntax of text, html, 
xhtml are defined out-of-band in the Atom RFC's.  I'd like to make it 
possible to define them in-band in a feed dcoument.

        /r$

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Feb 2009 08:56:54 -0800

> server is expecting to see?
That's a different case.  A schema link within the atom:entry is used to 
identify the schema of the top-level element within atom:content. Schema 
links within the atom:feed can be used to identify the schema(s) of the 
types of top-level elements that should appear within the feed. Those 
are two separate cases, neither of which requires the invention of the 
for attribute.

> possible to define them in-band in a feed dcoument.
This is fine but if you go down this route, there are many issues that 
need to be dealt with. If you allow schema links at the atom:feed, does 
that mean the content of all entries in the feed has to conform to that 
schema? What if the entry has a schema link that conflicts with a feed 
level schema link? What if there are multiple schema links that specify 
the same value for the for attribute? If you take an entry from an 
atom:feed containing a schema link and put it into another feed, should 
the schema link be added to the entry or should an atom:source element 
be added containing the schema link? I think you need to very clearly 
define how this is all going to work.

- James

---

From: Richard Salz <[email-masked]>
Date: Tue, 3 Feb 2009 06:34:23 -0500

It's an interesting idea.  You could get similar effect by using xml:id. 
But then there's no way to specify in an atom:feed what data the server 
wants (or will be providing) for the atom:entry's.

        /r$

---

From: Richard Salz <[email-masked]>
Date: Tue, 3 Feb 2009 12:11:41 -0500

> Schema 

Yes, since atom:content can only have a single child element, then the 
@for is superfluous.  But I don't understand how to meet the feed issue 
without the @for -- can you show me how?  Let's say I have a feed that 
accepts tns:esb entries and snl:foobar entries.

> need to be dealt with.

It's not clear to me that every single semantic needs to be completely 
nailed down (viz, 
http://www.dehora.net/journal/2009/02/03/just-use-post/).  Looking at RFC 
5005, what if a feed contains multiple conflicting archive links?  I'll 
meet the requirements, I just don't want to be a special case :)

        /r$

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Feb 2009 09:26:04 -0800

FWIW, you should probably also be looking at how to provide some of this 
information in the Atompub Service Document.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Feb 2009 18:20:53 +0100

> define how this is all going to work.

In particular, what happens to the rule "ignore foreign markup"? 
(<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.6.3>)

Wouldn't a server that XML-Schema-validates a given part of the document 
be violating this principle (unless it's a schema that has been 
explicitly designed to allow foreign markup)?

BR, Julian

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Feb 2009 09:21:20 -0800

> accepts tns:esb entries and snl:foobar entries.
A schema-link-aware client is likely going to be able to look at the 
schema itself to determine what kind of element is defines without the 
use of the for attribute.
> meet the requirements, I just don't want to be a special case :)
Of course there's no need to define everything but there are simple 
steps you can take o reduce the number of things that need to be explained.

- James

---

From: Richard Salz <[email-masked]>
Date: Tue, 3 Feb 2009 12:25:27 -0500

> (<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.6.3>)

That's a requirement on clients receiving Atom, and not atompub servers, 
isn't it?

        /r$

---

From: Richard Salz <[email-masked]>
Date: Tue, 3 Feb 2009 12:51:50 -0500

> use of the for attribute.

But that requires the client to fetch all the schema's that are defined. 
That's probably okay for a client that is creating entries, since it will 
be set up to only write a specific set of entries anyway, but it's not 
clear to me that it's okay for a client that is GET'ing entries.  If 
people feel strongly that @for is a premature optimization, oh well.

> steps you can take o reduce the number of things that need to be 
explained.

I will take another look at your questions.

        /r$

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Feb 2009 18:59:33 +0100

> That's a requirement on clients receiving Atom, and not atompub servers, 

OK, let's try 
<http://greenbytes.de/tech/webdav/rfc5023.html#rfc.section.6.2> then:

"Processors that encounter foreign markup MUST NOT stop processing and 
MUST NOT signal an error. Clients SHOULD preserve foreign markup when 
transmitting such documents."

BR, Julian

---

From: Richard Salz <[email-masked]>
Date: Tue, 3 Feb 2009 13:05:52 -0500

> <http://greenbytes.de/tech/webdav/rfc5023.html#rfc.section.6.2> then:

That seems to refer only to the category and service documents.

I think section 4.4 dominates -- the server can do whatever it wants with 
the content that is submitted.

        /r$

---

From: Richard Salz <[email-masked]>
Date: Tue, 3 Feb 2009 13:10:06 -0500

Going through the questions you posted earlier:

> If you allow schema links at the atom:feed, does that mean
> the content of all entries in the feed has to conform to that 
> schema?

Any content that has a schema is expected to conform to that schema. If a 
client does a GET, there may be entries that are not described by a 
schema; there is no requirement that every entry have a schema link. I 
thought that was obvious -- do I need to make it explicit?  If a client 
POST's an entry that does not conform, the server may reject it. I also 
thought that was obvious under section 4.4 of 5023.

> What if the entry has a schema link that conflicts with a feed level 
schema link?

This is described in the proposal: on GET, the entry-level link takes 
precedence.  POST is described above.

> What if there are multiple schema links that specify the same value for 
the for attribute?

And same type of schema language?  A very good question.  My preference 
would be to say that this is sytem-dependant, subject to the whims of the 
validating behavior.

> If you take an entry from an atom:feed containing a schema link and
> put it into another feed, should the schema link be added to the entry
> or should an atom:source element be added containing the schema link?

Is it really necessary to answer this? Can't it be left up to the server?

        /r$

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Feb 2009 11:24:54 -0800

> thought that was obvious under section 4.4 of 5023.
Ok, so this implies that entries contained in an atom:feed do not 
inherit the schema links of the parent atom:feed.  That's a good thing 
and should be stated explicitly.
> precedence.  POST is described above.
See above. As long as the atom:entry is not expected to inherit the 
schema link of the atom:feed, this is not an issue.
> would be to say that this is sytem-dependant, subject to the whims of the 
Works for me.
> Is it really necessary to answer this? Can't it be left up to the server?
If the atom:entry does not inherit the schema links of the atom:feed 
this becomes a non-issue.

- James

---

From: Nikunj Mehta <[email-masked]>
Date: Tue, 3 Feb 2009 12:08:25 -0800

This proposal seems to cover two very distinct use cases:

1. Provide a way to discover the schema used for the foreign markup  
used in an entry served by a feed server
2. Issue a contract to be used by the client to submit new entries to  
the server

For 1, this proposal seems to create an alternative to XML Schema  
instance mechanisms [1]. Any foreign markup in an entry, including  
that which is present inside the atpm:content is free to add the xsi  
markup to help the processor identify the schema by which that element  
should be processed. Of course, this mechanism works only for W3C XML  
schema-based documents. The present proposal is weakened by the  
presence of such an existing mechanism for the first use case. To  
illustrate this, take the following example:

<feed>
   <foreign:meta
     xmlns:foreign="urn:foo"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:foo http://example.org/schema">
       ...
   </foreign:meta>
   ...
   <entry>
     <foreign:markup
       xmlns:foreign="urn:foo"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="urn:foo http://example.org/schema">
         ...
     </foreign:markup>
     <content type="application/xml">
        <foreign:markdown
           xmlns:foreign="urn:foo"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:foo http://example.org/schema">
           ...
       </foreign:markdown>
     </content>
   </entry>
</feed>

For the second use case, it is best to provide this information in the  
context of a collection's metadata alongside existing constraints on  
what a server may (or not) accept. app:collection serves the purpose  
of just such a container and can be used inside a feed. One of the  
necessary things here might be the target for usage of elements from  
some foreign (non XHTML and Atom) namespaces. For example, a feed may  
advertise what data can be added to it thusly:

<feed>
   <app:collection>
     <contract:accept>
	<contract:element
             parent="atom:entry"
             schema="..."
             type="..."
             namespace="...">named_element</contract:element>
	<contract:element
             parent="atom:content"
             schema="..."
             type="..."
             namespace="...">named_element</contract:element>
         ...
    </contract:accept>
     <app:accept>application/atom+xml</app:accept>
     ...
    </app:collection>
    ...
   <entry>
     <foreign:markup
       xmlns:foreign="urn:foo"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="urn:foo http://example.org/schema">
         ...
     </foreign:markup>
     <content type="application/xml">
        <foreign:markdown
           xmlns:foreign="urn:foo"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:foo http://example.org/schema">
           ...
       </foreign:markdown>
     </content>
   </entry>
</feed>

Nikunj

[1] http://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation
On Feb 3, 2009, at 8:11 AM, James M Snell wrote:

>
> Rich,
>
> I'm not yet convinced that the for attribute is necessary.   
> Presumably, the schema format itself will be capable of identifying  
> which elements it defines, meaning that a schema-aware processor  
> could identify which schema to apply with relative ease.  Further,  
> since the atom:content element is only going to have a single top- 
> level element, it would follow that within a single atom:entry  
> element, there'd only ever be reason for a single schema link in the  
> entry.  schema links at the feed level don't make a lot of sense to  
> me since the schema link itself is part of the entry metadata.  
> Lastly, schema links at the feed level imply some kind of  
> inheritance model for atom:link elements (e.g. an entry would  
> inherit the schema links of the parent feed). The challenge with  
> atom:link and experience has shown that inheritance is not  
> necessarily a good thing.
>
> My suggestions would be to drop the for attribute, limit the schema  
> link to one instance per entry, and do not use schema links at the  
> atom:feed level at all.
>
> - James
>
> Richard Salz wrote:
>> This is close, the link/@for values would actually be  
>> "for='foo:blarg'" for example.
>>
>> I went back to the RFC and re-read 4.1.3.1.  It appears that you  
>> are right, multiple top-level elements inside atom:content are not  
>> allowed. Rats.  But we still need link/@for for use at the feed  
>> level, where individual atom:entry/atom:content elements might have  
>> different types of content.  Does that make more sense?
>>
>> document, but other discussion convinced our group that "content"  
>> belonged in atom:content.  When I made that change I didn't go back  
>> and carefully check this.  Sorry.)
>>
>>        /r$
>>
>> --

---

From: Keith Fahlgren <[email-masked]>
Date: Tue, 03 Feb 2009 12:25:31 -0800

On 2/3/09 12:08 PM, Nikunj Mehta wrote:
>
> 1. Provide a way to discover the schema used for the foreign markup used
> in an entry served by a feed server
> instance mechanisms [1]

Just, FTR, both of these are getting real world, adhoc implementations. At 
O'Reilly, an AtomPub server validates all of the collections that 
<accept>application/docbook+xml</accept> against the DocBook 4.4 DTD (our fave) 
(so XSI isn't useful). Additionally, we're talking about (so XSI isn't useful) 
Schematron validation to ensure that all entries in a Collection have embedded 
RDF needed to identify them.

HTH,
Keith

-- 
Keith Fahlgren
Publishing Technology Engineer
O'Reilly Media

---

From: Richard Salz <[email-masked]>
Date: Tue, 3 Feb 2009 17:21:24 -0500

That's an insightful way of looking at it.

I don't think the usecase is weakened by the existance of XSD's 
schemaLocation attribute.  At least not within the Atom/AtomPub community, 
which seems to like RelaxNG as its schema language.

Putting schema links in the collection document make sense.  But having 
them in the feed document provides a contract to those doing GET, as well 
as those doing POST.

        /r$

---

From: Nikunj Mehta <[email-masked]>
Date: Tue, 3 Feb 2009 15:34:00 -0800

On Feb 3, 2009, at 12:25 PM, Keith Fahlgren wrote:

> Just, FTR, both of these are getting real world, adhoc  
> implementations. At O'Reilly, an AtomPub server validates all of the  
> collections that <accept>application/docbook+xml</accept> against  
> the DocBook 4.4 DTD (our fave) (so XSI isn't useful). Additionally,  
> we're talking about (so XSI isn't useful) Schematron validation to  
> ensure that all entries in a Collection have embedded RDF needed to  
> identify them.

I don't find xsi very useful either, especially if the schema is  
defined in a MIME-type. In the absence of a dedicated MIME-type for  
the contents of the atom:content element with @type="application/xml",  
though, we need something in the app:accept block.

---

From: Nikunj Mehta <[email-masked]>
Date: Tue, 3 Feb 2009 15:32:19 -0800

> which seems to like RelaxNG as its schema language.

No matter what language you are using to describe schemas, an approach  
that marks the location of a schema document used for an XML namespace  
appears superior, IMHO. This allows flexibility of adding markup at  
any level inside an entry document and not just in the atom:content  
block, which happens to be another real-world use of Atom syntax.
> them in the feed document provides a contract to those doing GET, as  

There is a very well established precedent that any contracts related  
to POST should appear in the app:collection. The category and accept  
blocks are testimony to this. Moreover, one can treat the proposal  
primarily as a way to qualify

<app:accept>application/xml</app:accept>

and that can be done as one of the two mechanisms below inside the  
app:collection element:

<app:accept schema:namespace="..." schema:element="...">application/ 
xml</app:accept>

    <contract:accept>
	<contract:element
            parent="atom:entry"
            schema="..."
            type="..."

---

From: Keith Fahlgren <[email-masked]>
Date: Tue, 03 Feb 2009 16:21:30 -0800

On 2/3/09 3:32 PM, Nikunj Mehta wrote:
> <app:accept schema:namespace="..."
> schema:element="...">application/xml</app:accept>

Hmmm... I've got a problem with my DocBook 4.4 not being namespaced & using a 
DTD whereas my DocBook 5 using RNG, has a @version, and a namespace.

Is this how I say that my collection only accepts DocBook 5?
   <app:accept schema:namespace="http://docbook.org/ns/docbook"
               schema:type="application/relax-ng-compact-syntax"
               schema:link="http://www.docbook.org/xml/5.0/rng/docbook.rnc"
               schema:version="5">application/docbook+xml</app:accept>

and @schema:element="book" would mean that I only allowed 
{http://docbook.org/ns/docbook}books?

Thanks,
Keith

---

From: Nikunj Mehta <[email-masked]>
Date: Tue, 3 Feb 2009 16:45:34 -0800

Just to clarify, you are referring to the media portions of AtomPub as  
opposed to Richard Salz who is looking to support the Atom entries.

The <app:accept> extended attribute mechanisms you suggest are a good  
way to do media resources. The <contract:accept> extended element  
mechanism I suggested in [1] seems better suited to non-media Atom  
entries.

Nikunj

[1] http://www.imc.org/atom-syntax/mail-archive/msg20912.html

On Feb 3, 2009, at 4:21 PM, Keith Fahlgren wrote:

> Hmmm... I've got a problem with my DocBook 4.4 not being namespaced  
> & using a DTD whereas my DocBook 5 using RNG, has a @version, and a  
> namespace.
>
>
> and @schema:element="book" would mean that I only allowed {http://docbook.org/ns/docbook 
> }books?
>
>
> Thanks,
> Keith
> -- 
> Keith Fahlgren

---

From: Richard Salz <[email-masked]>
Date: Tue, 3 Feb 2009 21:22:20 -0500

> appears superior, IMHO.

That doesn't work for schema languages that do not support XML namespaces, 
such as DTD, ASN.1, DMTF, etc.  (I am currently most interested in the 
last.)

> to POST should appear in the app:collection.

And for GET'ing a feed or entries? 

> Moreover, one can treat the proposal primarily as a way to qualify
> 

The schema link relation does more than just tell POST'ers what it will 
accept; it tells GET'ers what they can expect to receive.  As I expect 
readers to outnumber writers, that latter is very important.

        /r$