- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Wed, 16 Jan 2002 10:27:22 -0500
- To: Martin Gudgin <marting@develop.com>
- CC: Marc Hadley <marc.hadley@sun.com>, XML dist app <xml-dist-app@w3c.org>
Martin, MUST NOT be required is different than saying MUST NOT be used. IMO, we have tghe restriction on "required" on the part of a recipient of a message, but we do not, nor IMO can we preclude the receiving SOAP node from applying whatever processing floats their boat. A receiver *could* leverage the knowledge that the attributes named 'id' and 'idref' are implicitly typed as XML1.0 ID and IDREF, construct a DTD that it used to process the message. Cheers, Chris Martin Gudgin wrote: > ----- Original Message ----- > From: "Christopher Ferris" <chris.ferris@sun.com> > To: "Martin Gudgin" <marting@develop.com> > Cc: "Marc Hadley" <marc.hadley@sun.com>; "XML dist app" > <xml-dist-app@w3c.org> > Sent: Wednesday, January 16, 2002 2:01 PM > Subject: Re: IDREF vs HREF for graph edges in SOAP encoding > > > >>Only if one wanted to leverage the internal subset, >>other than that, you could treat them in the same >>manner as href and id. >> > > Sorry, this may be the context I'm missing. Are we saying that we will use > attributes with local names of ID and IDREF rather than attributes with type > of ID and IDREF? If the former then we don't need DTD/schema processing but > at the same time I guess I'm not entirely sure what the difference is > between ID/IDREF and id/href. If the latter then surely we need DTD/schema > processing to determine which attributes are of type ID/IDREF > > >>It would certainly be much >>more convenient for implementations that did choose >>to leverage DTD processing. >> > > This leads me to think we're talking about type rather than local name > > >>Given that we're talking >>about encoding, which leverages XML Schema types, it >>is pretty clear to me that we're also imposing schema >>processing anyway, no? >> > > My understanding is that our spec specifically states that schema processing > MUST NOT be required. > > Gudge > > >
Received on Wednesday, 16 January 2002 10:28:43 UTC