Re: IDREF vs HREF for graph edges in SOAP encoding


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.



Martin Gudgin wrote:

> ----- Original Message -----
> From: "Christopher Ferris" <>
> To: "Martin Gudgin" <>
> Cc: "Marc Hadley" <>; "XML dist app"
> <>
> 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