Re: [mile] Artart last call review of draft-ietf-mile-rolie-10

[Martin Thomson <[e-mail]>]

On Sat, Nov 4, 2017 at 2:52 AM, Banghart, Stephen A. (Fed)
<[e-mail]> wrote:
> Martin,
>
> Could you clarify which XML issues you mean? The rolie:format / rolie:property elements or something else?
>
> rolie:format is necessary beyond media types for differentiating between formats that don't have their own media type, and for making clear the difference between a "media type" and a "format". Media types provide information about the serialization of content, but don't actually define the model of the content. Schemas can be used to help the parser understand the content, rolie:format provides a means to describe both the model and the schema of the content. We could solve this by providing some modified media type, but this would require just as much specification as our current solution. As an example, how would we best specify to a consumer that the content element links to an IODEF document? It's media type is XML, but there remains information that can only be gleaned  by downloading the entire content file.

You describe the exact purpose of a media type.  The advantage of
media types being that the type is available in more places than just
a ROLIE Feed.  For instance, you can use content negotiation in HTTP
to ensure that you get something you can consume.

I'm not saying that this is more or less specification, it's just that
you get more value from a media type than you do with this sort of
mechanism.  Even if it means minting a few more media types.

Furthermore, identifying a schema is usually inadequate to describe
the relevant parts of an XML format.  There are many generic container
formats in XML for which listing the top-level schema is pointless.
ROLIE itself suffers from this because it uses Atom.  It's not even
possible to list schemas, because that loses critical information
about what elements are used in what contexts.  In order to properly
capture the full transitive closure of formats, you need something
considerably richer (I once thought that this worth doing/possible,
but that idea was quickly abandoned without really testing it fully:
https://tools.ietf.org/html/draft-thomson-simple-expressing-xml-support-00).

> rolie:property has a couple of advantages over defining the key-value pairs in XML. Defining new elements in XML is expensive. In the ROLIE core document we define 4 new properties, which would yield 4 new elements in the schema. In our Software Descriptor we define another software specific property, and we may add more as we iterate the draft. There are two other extensions in development that may add new properties as well. rolie:property provides a means to easily define new properties without generating a huge number of new elements.

I disagree on the XML - the amount of effort you put in to define your
XML properties is pretty minimal: a namespace and schema, plus
semantics of each of the fields.  You gain the ability to properly
constrain the grammar (for example, you could use xs:dateTime for
content-updated-date instead of prose).  You have demonstrated how
easy that can be in this document (by defining rolie:property itself).

I've dealt with extensible fields like this in the past (see RFC
6848), and it's no more difficult to pair up ns+localname and simple
value than it is to pair up URN and simple value.

As proposed, you also have a new registry for these fields, which is
strictly more costly.

p.s., I thought you were going to remove
"urn:ietf:params:rolie:property:local", but it is still in -13.  That
would of course be moot if you did as I suggest.

> Would it be useful to clarify this further in the specification, or do you still have technical concerns?