JUNOScript draft - comments

[Graham Klyne <GK@NineByNine.org>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to
 miss and therefore delete mis-posts.  so fix subscription addresses! ]

[I've been asked to post these comments to XMLCONF ... please note that 
they were prepared with a different audience in mind, so please be tolerant 
if some of the comments seem out of place in this context.  Also, I'm not 
subscribed to this list, so please cc me if you have any comments 
specifically for me.  Thanks.  #g]


Reading Phil Shafer's and Rob Enns' draft [1]:  these comments are not 
intended as a critique of JUNOScript, but of how it relates to and 
illustrates discussions about XML use in the IETF.

[1] http://www.ietf.org/internet-drafts/draft-shafer-js-xml-api-00.txt

...

Section 1.1:  simplicity (explain in 2 paragraphs) I think completely 
removes ideas of "XML as transport" from the picture.  (Actually, I think 
it might take DTD's/schemas out of the picture.)

Extensibility:  I think this deserves some more discussion.  I view "basic" 
XML as having limited extensibility, in the same sense that (say) RFC822 
has limited extensibility -- extensions require some kind of coordination 
of naming.  I would suggest XML+namespaces are a basis for more 
decentralized extensibility.  This takes us into the URIs-as-identifiers 
area that I mentioned previously.

Rigidity:  is this really an advantage?  (c.f. extensibility.)  Sometimes 
it may be, but I'd say not always.

Web tie-ins:  "Data that is not stored in a database is usually presented 
directly to users".  I'd not agree with this.  I think there are a number 
of non-database XML application formats that are generally not presented 
directly to users.  XML schema and XSLT are a couple that occur to me off 
the top of my head.  There are others that relate to information presented 
to users, but not the XML element directly -- RSS springs to mind.


Section 2.3

Encoding issue.  I'd need to check, but I'd expect most SOAP 
implementations to permit the use of unencoded XML as well as encoded 
application data (which I am guessing is the intent of Apache literalXML 
encoding).

(Use of BEEP:  I'd suggest that multiple outstanding RPCs could be handled 
in a single BEEP channel, using BEEPs inherent pipelining 
capability.  Marshall has indicated that a single-channel BEEP 
implementation can be very simple compared with the full-strength 
multi-channel flavour.)


Section 2.5:

FWIW, I think the "severe" treatment of framing protocol errors is 
right.  I recall there was similar discussion concerning BEEP (or was it 
APEX?) with similar conclusions being reached.

I think this section very nicely raises the potential issues of combining 
framing and content in a single protocol format.  I don't think it's always 
wrong to combine them, but  there is a price.  It is to address such issues 
that I've suggested the possibility of a MIME profile that deals only with 
content framing/encapsulation issues, via multipart/related or similar.  It 
has the advantage that opaque content can be passed to an application 
without requiring detailed analysis or parsing.  (Something like this can 
be seen in the design of APEX, and also in my RFC822-XML proposal [2].)


Section 4.1:

Phil has commented elsewhere about the "wide open" nature of XML.  I think 
an aspect of this can be seen here, where XML is being used to encode both 
procedural commands and non-procedural configuration data.  It would be 
very easy for these to become confused.  I'm not saying they are confused 
in the JUNOScript description, just noting the possibility;  indeed, I 
think the existence of a non-XML configuration syntax helps to maintain 
some distinction here.


Section 4.2.1:

I tend to agree with the comments about using XPath for subset 
specification.  In my view, XPath is very XML-bound, and may be a 
reasonable choice if the application data model is truly the same as the 
XML data model.  But we've already seen in sections 4.1.2 that the 
configuration data model for JUNOScript, while similar in some respects to 
the XML model, is also different and that specific XML structures need to 
be defined to represent them.  I think to then use XPath for selection into 
that structure would be in danger of having the tail wagging the dog here.

The point I'm trying to get to is that the XML data model (roughly, an 
annotated tree with some free-text leaf elements) isn't necessarily a 
substitute for a well-considered application data structure.  Other efforts 
I've been involved with have run into difficulties (IMO) in part because of 
this failure to separate XML as a carrying syntax from the underlying 
application data model.

For example, a particular area where I've seen this kind of issue arise is 
ordering.  The XML tree is inherrently ordered (i.e. the 
elements).  Application data sometimes is not.  Imposition of XML ordering 
can create artefacts with respect to the application data.  For example, if 
I read it correctly, the JUNOScript <load-configuration action="merge"> 
operation has to explicitly disregard ordering in the command's XML tree 
and corresponding configuration data with which it is merged, or the 
required matching may not work as intended.  The situation for "replace" 
seems to be similar.  XML doesn't help here, and the application has to be 
clear about how it behaves.

"Configuration groups" (section 6.5) seems to be another area where the 
application needs are not fully reflected by the XML data model.


Section 5.1

I think similar data model considerations to those mentioned above also 
apply to commands.  The specific RPCs are all encoded using defined XML 
structures:  in this, the XML encoding for each command is hand made 
according to the needs of the command.  I guess that the fact of there 
being a text CLI form probably helps to enhance this distinction.

My point is similar:  the purpose and parameters of each command are 
application issues, separate from their XML-encoding.

This line of exploration seems to lead toward generic RPC marshalling 
frameworks (XDR, DCE, CORBA, etc.)  I note that JUNOScript avoids the 
overhead of adopting a generic encoding scheme -- this happens to concur 
with my own prejudices in the matter:  I've yet to be convinced that 
there's widespread practical value in a generic encoding schemes, as 
opposed to using hand-crafted command/parameter formats.  In a sense, I 
think XML reinforces this, in that it makes it very much easier to define 
command/parameter formats by hand.  I could be persuaded otherwise, but I 
do think that for simple applications, the effort of defining an XML 
syntax, and parse it using off-the-shelf XML tools, is small compared with 
the effort to design the underlying application logic.


Section 6.1

XML SChema vs DTDs:  I'll note here that the group discussing 
draft-hollenbeck-ietf-xml-guidelines [3] spent some time discussing the 
choice of XML schema or DTDs and didn't reach any clear consensus (see 
section 4.7).

XML schema is disliked by many in the W3C community, for being over-complex 
and yet failing to do everything that DTDs can do.  The points in the 
JUNOScript draft about use of XML are well made.  But they do (to my mind) 
raise a question about readability of XML.  AT the level of debugging and 
bootstrapping, XML can reasonably be described as human readable (c.f. [1] 
section 1.1), but for everyday use I find it not so.  XML is primarily a 
general-purpose machine-readable format, and as such I find it performs 
poorly as a human-usable specification format.  I see no clear answers to 
this dilemma. (I could imagine a non-XML form of XML schema that can be 
readily translated into XML-schema.)


Section 6.2

I think this touches on an important area of extensibility in XML.  The 
solution offered for JUNOScript seems fine in that context, but I do think 
there are other contexts where extensibility could be better served.

Example:  consider a converse case where a device management station is 
used to construct a complex configuration which is passed to all 
devices:  it may contain configuration information that is not included in 
the known configuration of all those devices.  Such configuration 
information would be ill-formed according to the published schema for some 
devices.  Another approach is to allow arbitrary extensibility, but provide 
that a device will discard those portions that cannot be matched according 
to their schema.  This could allow for more free extension and phased 
upgrading of devices without having to generate separate configuration files.

(Section 6.3 gives another example.)

XML schema does provide some facilities for open-ended 
extensibility;  elements that can be so extended must be identified by 
inclusion of specific descriptive elements.


Section 6.4

I'm puzzled why the comment text has to be /*...*/ or #...
I'd have thought the enclosing <junos:comment> was sufficient.

Hmmm... is 'junos:' a defined XML namespace prefix?


Section 6.5

(See comments on section 4.2.1)


Section 6.6

Whitespace:  I think there's some XML spec dealing with similar issues, but 
I don't recall where, offhand.


Section 6.7

I think the dereferencing of namespace URIs is in keeping with current W3C 
thinking (per W3C TAG architecture document [4] and issue list [5]).


Section 6.8

Encoding issues:  I'd think the approach of equivalently allowing 
attributes or elements might be stretching the capabilities of XML schema 
(e.g. if only one instance of a given property is permitted, I don't think 
the scheme can prohibit (i.e. frail validation) both attribute and element 
from appearing together.  Then, which takes precedence?

This is a nit, and easily enough overcome, but I think it illustrates again 
the fact that an application data model may not perfectly match XML's data 
model (see comments on 4.2.1).


...

I think this draft [1] is a useful illustration of a number of issues for 
using XML in a protocol context, illustrating both its strengths and 
weaknesses.

#g
--

[1] http://www.ietf.org/internet-drafts/draft-shafer-js-xml-api-00.txt

[2] http://www.ietf.org/internet-drafts/draft-klyne-message-rfc822-xml-03.txt

[3] 
http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-06.txt

[4] http://www.w3.org/TR/2002/WD-webarch-20020830/
    http://www.w3.org/TR/2002/WD-webarch-20020830/#pr-describe-resource

[5] http://www.w3.org/2001/tag/ilist#namespaceDocument-8


-------------------
Graham Klyne
<GK@NineByNine.org>




--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>