RE: TAG issues brainstorming


1. System architecture document.  We should describe the way the web
currently works, leveraging Tim's dependency diagram.  This should also help
with MB's issue that he doesn't believe HTTP is well enough understood.
Rational has a leading methodology for software architecture, described in  If we chose this
methodology, I don't think we need to go into all the views.  A logical
view - showing dependencies (uses relationships) - plus a physical view
would be a good start.  I'm very open to other methodologies as well, I
simply list this one as an industry standard.  This document would also list
open issues, such as my issues #2-#5.  I suggest that we adopt a methodology
from industry rather than creating our own.

2. Packaging.  Packaging of XML and potentially non-xml documents into a
bundle for file system storage or transmission is currently not specified in
the W3C.  There are related efforts, like Soap with attachments, DIME, and
others that should be examined for adoption.  The W3C membership has clearly
indicated it has no interest in allocating resources to this work, though
most acknowledge it is an important and open issue.  I argue that it is
because of "boringness" of packaging that the work is not a high priority,
as opposed to technical rationale.

3. Profiles.  It would be beneficial to describe common profiles of XML
processing.  Vendors could easily describe the functionality of the
software, and users would be able to more easily understand and use the
integrated components.  Coherent conformance test suites are also easier to
write and test against.  There are 2 characteristics that may be worthwhile
profiling: message content and application apis.  Examples of these are: XML
1.0 without PIs/DTDs + Namespaces + XML Schema + XML Base (XML NG?); and DOM
Level 2 + XSLT 1.0 + SAX Level 2.  This clearly relates to packaging and
manifests.  There have been historical precedents to this notion - the J2EE
brand and definition continues to be a unifying and evolving force.

4. XML Processing model.   There was a processing model workshop in the
summer of 2001, a fair bit of interest in proceeding with a deliverable
around a processing model.  The W3C has made no public announcements about
any additional WGs or other activities, so the issues around xml processing
still remain.

5. XML Type library.  There are many calls for a type library - such as the
SOAP array structure, Name/Value pair, other collections - and this is not
in the XML Schema WG's charter.  Again, this was tremendously useful in the
Java context with the Java collections library.


Received on Monday, 17 December 2001 23:16:01 UTC