Re: CR-18 Response: Validating XPointer IDREFs?

Aki Yoshida wrote:
> 
> Dear Eric,
> 
> The W3C XML Schema Working Group has spent the last several weeks
> working through the comments received from the public on the
> Candidate Recommendation (CR) of the XML Schema specification. We
> thank you for the comments you made on our specification during
> our CR comment period, and want to make sure you know that all
> comments received during the CR comment period have been recorded
> in our CR issues list (http://www.w3.org/2000/12/xmlschema-crcomments.html).
> 
> You raised the point registered as issue CR-18:
> 
> Title: Validating XPointer IDREFs?
> 
> In particular, you asked whether XML Schema should provide a mechanism to
> check if or not the target of a document-internal URI-reference as used in
> IDREFs in XPointer really exists.
> 
> Resolution:
> The Working Group considered this issue at the f2f meeting in London and
> decided not to add this feature at this moment.
> 
> Adding some simple string-processing functions to the key/keyref mechanism
> may solve this particular IDREFs validation case but will not solve more
> general  cases.  On the other hand, adding more complex functions will
> significantly overshadow the benefits of the key/keyref mechanism over its
> complexity.  It seems that such constraint may be more appropriately
> implemented on top of the current XML Schema language, thereby not making
> the current spec more complex that it needs to be.
> 
> It would be helpful to us to know whether you are satisfied with the
> decision taken by the WG on this issue, or wish your dissent from the
> WG's decision to be recorded for consideration by the Director of
> the W3C.

Not really. 

I am still thinking that it would be much more flexible and powerful to
remove the restriction that a field must identity a node:

<quote>
This must identify a single node (element or attribute, not necessarily
within the
selected element) whose content or value, which must be of a simple
type, is used in the constraint.
</quote>

If a field was the result of a XPath expression without further
restriction, then the issue I have reported would be solved and it would
open many possibilities.

I don't see how the spec would become more complex by removing this
sentence and I don't think the implementations would be more difficult
either as one can expect that most of them will rely on existing XPath
implementations.

Furthermore, removing this restriction for the selector would probably
have more impact, but specifying that a selector is a XPath expression
having a type "node-set" would also open many interesting possibilities.

BTW, another point with which I am dissatisfied, although not directly
related to the spec, is the fact that despite many requests to many
people my request to be subscribed to this list hasn't been taken into
account, making it very difficult for me to track the progress of this
spec.

Best regards,

Eric van der Vlist

> Regards
> 
> Aki Yoshida
> XML Schema Working Group

-- 
See you in Austin (Knowledge Technologies 2001)
              http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------

Received on Thursday, 15 February 2001 04:20:58 UTC