I have not had a chance to study XML at all. However, for those working
on XML encoding proposals for representing IPP requests and responses, I
thought it would be helpful to write down the requirements that we
evolved in doing the current IPP Protocol Encoding to help those doing
XCL proposals.
Our current IPP protocol encoding is described in:
<draft-ietf-ipp-protocol-04.txt>. The 05 version has been forwarded
to the internet-drafts DL and will be out shortely. It is currently available
at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980109.pdf
Strawman Requirements for encoding IPP protocol using XML
1. Do not need to change the IPP Model document at all, or only at least
trivially. It has all of the semantics that we want to represent.
2. Need to be able to represent all of the attribute syntaxes (data types)
that are in Section 4.1 of the Model document: text, textWithLanguage,
name, nameWithLanguage, keyword, enum, uri, uriScheme, charset,
naturalLanguage, mimeMediaType, octetString, boolean, integer,
rangeOfInteger, dateTime, resolution, and 1setOf X (multi-valued attributes).
2a. A different, more natural to XML, method for overriding the
natural language for 'text' and 'name' attributes than using the
'textWithLanguage' and 'nameWithLanguage' attribute syntaxes
would be acceptable.
3. Keywords are used to identify attributes and attribute values and
are specified in lower case US-ASCII and U.S. English and allow hyphen (-),
dot (.) and underscore (_).
3a. Using keywords to identify attribute syntaxes would be desirable,
though not currently done in our current IPP protocol.
4. Implementors must be able to add private keywords using private
keyword syntax for which clash with other implementors' private
keywords is not possible.
5. The PWG must be able to add additional attribute syntaxes
following a registration procedure that includes PWG review.
6. Implementors must be able to include priviate attribute syntaxes
in conforming interchange.
6a. It would be desirable if clashes with other implementor private
attribute syntaxes could be guarranteed to be avoided - something that
our current IPP encoding does not solve, since attribute syntaxes are
encoded as integers without a registration scheme. Using keywords
for attribute syntaxes would be a way to achieve such name clash avoidance.
7. Implementors must be able to add private enum values.
8. Attributes must be identified by keywords in US-ASCII and US-English.
9. Attributes must be able to be multi-valued.
10. Some attributes must be able to have more than one attribute syntax
defined for them, such as 'keyword' and 'name' (or 'text' and
'textWithLanguage' if that mechanism is used for overriding natural language
on an attribute value by attribute value basis).
11. An instance of a multi-valued attribute must be able to employ
any of the attribute syntaxes defined for it. For example be able to
mix 'keyword' and 'name' values.
12. Each value of an attribute needs to identify which attribute
syntax it is using.
13. The 'text' and 'name' attribute syntaxes must be able to represent
any ISO 10646 character, probably using utf-8 encoding.
14. The 'text' and 'name' attribute values must be representable in other
charsets than utf-8. Possibly, some simple coding transformation may be
required by the client for some charsets. There is no need for this
to be done on an attribute by attribute basis. Only a sinlge request
or a single response needs to be in a charset specified in the interchange.
15. It must be possible to group attributes in an interchange into several
groups. For requests:
Operation attributes and Job Template attributes
For responses:
Operation attributes, Job Attributes, Printer Attributes,
Job Description Attributes, Printer Descriptions Attribute,
Unsupported Attributes.
16. No syntactic distinction is needed between multi-valued attributes that
are ordered, and ones that are not. The semantics specify which attributes
are odererd and which are not (most are not).
17. Similarly, no syntactic distincation need be made between attribute groups
that require certain attributes to be first and ones that do not.
The semantics specify which attributes must come first in which groups.
Most attribute can occur anywhere in the groups in which they are permitted.
Comments?
Tom