On 2015-12-04 15:06, Erik Wilde wrote:
On 2015-11-25 11:09, Julian Reschke wrote:
I don't believe that all of my WGLC feedback from December 2014 has been
addressed (and that includes subjects on where we agreed on changes).
See
<http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13453.html>.
quoting from this message, these changes should address your issues:
2) The spec talks about using Accept to instruct the server whether to
return problem details or HTML. Maybe it would be worthwhile to
mention that if you use XML, you could *always* send problem details,
and then use <http://www.w3.org/TR/xml-stylesheet/> to instruct the UA
to convert to HTML; that would get rid of the conneg complexity.
https://github.com/dret/I-D-1/commit/6f37bcaca5a5295a76592231a1a614b0f0f76957
should take care of this. it recommends to use XSLT 1.0.
The data model for problem details is a JSON [RFC7159] object; when
formatted as a JSON document, it uses the "application/problem+json"
media type. Appendix A defines how to express them in an equivalent
XML format, which uses the "application/problem+xml" media type.
Why is this an appendix?
i am honestly not sure about this. mark preferred to have it as an
appendix, and since he is the main author, that's where it ended up.
The OPTIONAL RELAX NG schema [ISO-19757-2] for the XML format is:
What does "OPTIONAL" mean here? The schema doesn't seem optional at
all; lacking it, you wouldn't even know what XML namespace to use.
the idea was to not mandate that people use RELAX NG. we picked RELAX NG
because it's easier to read than XSD, but the idea is that there should
be no normative schema because schemas never completely capture what's
in a spec. i agree that the term "OPTIONAL" may be a bit confusing here,
though, so i rephrased that section a bit.
https://github.com/dret/I-D-1/commit/46b02840131147b75795d64baa09ac1004e5e132
default namespace ns = "urn:ietf:rfc:XXXX"
This needs to state that it will be updated based on the assigned RFC
number.
https://github.com/mnot/I-D/blob/gh-pages/http-problem/draft-ietf-appsawg-http-problem-02.txt#L29
takes care of that.
Extension arrays and objects can be serialized into the XML format by
considering an element containing a child or children to represent an
object, except for elements that contain only child element(s) named
'i', which are considered arrays. For example, an alternate version
of the example above would appear in XML as:
This is written like guidance, but it's normative, right?
yes, these are the rules how it has to be done. does this rephrasing
work for you?
https://github.com/dret/I-D-1/commit/eac63fbd5659b89ac2a408987368f4e21030382e
<instance>
http://example.net/account/12345/msgs/abc
</instance>
It would be good to point out that due to the type definitions in the
schema, the whitespace inside <instance> is ignorable.
that may be more complicated and potentially confusing than to simply
fix the XML to not contain whitespace, right?
https://github.com/dret/I-D-1/commit/69c39606c4087c53710695124cdb9020a5438ac3
https://github.com/mnot/I-D/pull/165 is where all the commits live for
now, i hope they are addressing all of your issues?
thanks and cheers,
Yes, I believe so. Thanks.
Best regards, Julian