TB summarizes his issues: I have some technical issues with
directions proposed by Query WG. Sharpest aspect is that parts of Query
require XML Schema semantics. I sent info to XML Query WG; received a
short reply; since then I've received longer replies from individuals
of the group.

My latest
message is an attempt to break down the problem. This may be a
process issue rather than an arch issue. We are moving beyond DTDs
(after decades) into new territories of schemas. It seems to me at this
point highly architecturally unsound for any really important
Recommendation to bet the farm on a particular schema language. XQuery
is bigger than it needs to be. The WG has done the sensible thing of
defining Basic Query (leaving out most of schema bits). There needs to
be architectural pressure on groups to do less; ship sooner; ship
simpler.

PC: Sorry for not replying in a more timely fashion to TB's points.
On the topic of required integration: WG chartered (twice) to use XML
Schema. There haven't been comments prior saying that this is a bad
thing. If this dependency is to be changed, then Query WG needs to be
rechartered.

[timmit]

Firstly, I am surprised that TimBray is not encouraging
interdependence between w3c specs - see HTML and Xlink discussion -
PC

[Ian]

PC: This makes this a process issue. IMO, the primary concern in
public fora is not dependency on xschema. But rather whether update
language is critical (public split 50/50). On living in a
multiple-schema world: Just because someone waves a standards banner
does not mean that the XML Query WG has to change its plans and delay
its work to pay attention to such a banner waver.: Perhaps the XML
world needs an abstraction that would include the various schema
languages. I think there's a work item in the schema charter that
covers this item.

From XML
Schema WG charter: "interoperability with other schema languages
such as RELAX-NG and Schematron"

On item three on simplicity: We have worked hard to meet our
requirements. To come along and say that the requirements are too big
surprises me. I don't think that WGs at W3C should be constrained to
pursuing only small specs.. Basic Query handles Schema Part 2. If we
publish Basic Query as our only deliverable, we would not meet our
requirements. I don't think that at this point in time we should split
our deliverables given the progress we've made on the document. I
think it's ok that the query spec is big. Some of the size has to do
with clearer expectations about interoperability. TB has identified a
long-term goal -- clearer relationships among schema specs -- but I
don't think that this should affect Query 1.0. There are a number of
XQuery 1.0 implementations, even prior to last call (both Member and
non-Member implementers). So TB's arguments sway me less since we have
so much implementation experience that suggests we are doing the right
thing.

DC: Is PC arguing that this or is not a TAG issue?

PC: Could be that the TAG issue is on multiple schema languages.
Perhaps we could synthesize an abstract model for PSVI processors.

DC: Is there an issue in the first place?: I'm convinced there's an
issue given the substantive email exchanged.

TB: Tie-in to XLink is a big bogus; the arguments in that case were
purely technical, not about it being a W3C spec.: In the community of
Web designers, there is a wave of horror at the astounding complexity
of schema and xpath 2.0. A strong feeling that something has gone amiss
somewhere.

DC: I have heard similar.

TB: I am not simply running off at the mouth here, but I think
accurately representing a feeling that's out there.

[Zakim]

DanCon, you wanted to share concerns from the public about XML schema
"leaking" into other specs; mostly XPath and to say that nearing last
call is *exactly* the time to revisit and confirm or reconsider
requirements.

[Zakim]

Timmit, you wanted to say that this is primarily an architectural
issue in the sense of high-level modular design. It is a question of
whether a flexible interface to the schema language should be provided.
Of course the process and social issues are intertwined.

[Ian]

TBL: The question is architectural (whatever the charter said).:
Modularity is a good thing; can the specs be more modular? PC and TB do
talk to different people (and it's good to hear from all of those
people). It would be obviously costly to do anything to XQuery. I read
Xquery and it seemed pretty straightforward to me. PC's social point
holds (cost of change).

Timmit, you wanted to say that this sort of choice has to be made in
each case on its merits.

[Ian]

TBL: I am concerned by extreme stances such as "one should one always
use w3c specs"; each case is different. Several good principles here -
reuse stuff; modularity. Need to consider each case. Just talking about
the schema, case I think that it's not interesting to reset the Query
WG. What is possible is for someone to find a clever way of achieving
what is required. I haven't understood whether "Basic" is what TB
needs. Is Basic what TB prefers, or is Basic not adequate (and needs
tweaking)?

SW: Please frame comments in terms so we can define this issue.

TB: I think that it's a good thing to have lots of schema languages
out there since this area is new. We don't have enough experience to
know which schema language meets which needs. I highly approve of
XQuery Basic and would strongly recommend that the WG release that on a
separate Rec track. It might even shorten time to Recommendation (for
that part of the spec). I have argued (with specifics) about how
query/schema can be decoupled. I haven't heard substantive replies to
my specific syntax.

TB: issue proposal: "Schema languages: What can be said
about multiple existing schema languages and their appropriate uses in
W3C and the Web more generally?"

TBL: More specific than "What can be said about...?"

TB revised proposal: "Given the existence of more than one
XML schema languages; what architectural implications does the use of a
particular language have? To what extent is it useful to bind to all
schema languages or a particular one?"

DC issue proposal: "To what extent should schema be
integrated into xpath and xquery?" At confs I hear concerns about
XPath.

NW: I have a lot of the same concerns as TB. Though I'm not sure what
the issue is, exactly. I think the pragmatic issue will be setting the
conformance levels right. Substitution groups and inheritence look like
they'd be hairy to decouple.

[DanCon]

sigh. conformance levels are evil. This was a priniciple of XML 1.0
(which XML 1.0 didn't quite meet, actually) and it continues to be
important.

[Ian]

PC: What about extending DC's proposal to xforms and wsdl?

DC: Not concerned about those as much as xpath, and xquery.

NW: I'd support DC's proposal

PC: I vote against the issue as proposed. XQuery 1.0 handles DTD and
XML Schema. It's not been on the WG's work plan to handle other schema
languages. And it seems that the XQuery WG charter has as a work item
addressing additional schema languages. I don't understand why the TAG
has to take this up since the WGs have items on their work plans.

NW: I don't think that there's evidence that xquery and xpath will
support xml schema and dtds equally well.

RF: There seems to be an awful lot of support for Relax

SW Proposed: Adopt as a new issue "To what extent should xml
schema be integrated into xpath and xquery?"

PC: I oppose this as an issue; I don't see what the architectural
issue is from this wording.

For: DC, TB, NW.

Abstain: TBL, RF, SW

PC: If there an arch issue, I think it's about how schema languages
interrelate. I'd like to take offline with TB and refine this.

TBL: We can ack the inconsistency in the architecture (e.g., when
coneg is used). You can serve an HTML page as text/plan. You could
serve up, similarly, a bag of bits using the appropriate mime type to
give the meaning of a dog or car.

TBL: I have resisted bringing in mime types. I've become more
comfortable with the idea of using mime types to give a particular view
on data.: I think there is an issue here that we should write up.
Fortunately, I think we can write it up and resolve it.

[Straw poll]

PC: I'm uncomfortable about doing this without Chris Lilley
present.

DC: That doesn't convince me that we shouldn't call the question, see
if there's support today, and moving on.

SW: Active support for the proposed issue?

For: NW, TBL, DC, SW, RF

Abstain: PC, TB

[Norm]

People would like to be able to inject processing instructions (not
PIs, but semantics) into fragment identifiers. That's where I'm feeling
the pain today.

Completed action RF 2002/09/25: Propose a rewrite of a principle
(rationale -> principle -> constraint) to see whether the TAG
prefers this approach. It was suggested that the example be about
HTTP/REST, as part of section 4.

Completed action TBL 2002/09/25: Propose text on information hiding.
(From 24-25 Sep TAG ftf: "The principle of information-hiding is contrary
to global identifiers....Shall we put in the document something about
information hiding/independent design of orthogonal specs? You should
should not be able to write an xpath to peek into http headers....") [Done]

Roy
writes "I give up" as if to say "please withdraw this action" but I
found his message quite responsive to the action.

[Ian]

RF: Regarding earlier question: are xquery and xml schema
orthogonal?

TB, DC: I found the approach appealing.

IJ, SW: Same here.

IJ: "Change is inevitable, and therefore evolution should be
planned." Seems like "evolution shoudl be planned" is for agents, not
the system. Does "requirements" mean requirement on the designers or
the system?

RF: "The system needs to be be able to evolve since change is
inevitable."

TB: "Evolution should be planned *for*; when change happens things
should not fall apart."

TBL action regarding info hiding done.

CL Action about chapter three not done.

IJ: What are our expectations for doc before AC meeting?

PC: I am more comfortable approving 29 Oct draft and approving a
bigger change at the ftf meeting.

DC: I'd like IJ to get as much done as possible by 13 Nov, with
approval with one other TAG participant's review.

Resolved: We might not get a doc out by
13 Nov, but ok for IJ + two other participants (for this draft)
sufficient to get to TR page.

IJ: I will try to get a draft with some of RF's proposals by Thursday.