W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2009

[Bug 6513] [XQuery] inconsistent terminology in definition of derives-from()

From: <bugzilla@wiggum.w3.org>
Date: Tue, 15 Sep 2009 02:00:21 +0000
To: public-qt-comments@w3.org
Message-Id: <E1MnNLB-00058o-OY@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6513





--- Comment #15 from Jonathan Robie <jonathan.robie@redhat.com>  2009-09-15 02:00:21 ---
I propose that we solve this as follows:

1. In 2.5.4 SequenceType Matching, adopt the terms "in-scope" and "not
in-scope", similar to what Mike Kay proposed in comment #10:

Old:

  The given schema type may be "known" (defined in the in-scope schema
  definitions), or "unknown" (not defined in the in-scope schema
  definitions). An unknown schema type might be encountered, for
  example, if a source document has been validated using a schema that
  was not imported into the static context. In this case, an
  implementation is allowed (but is not required) to provide an
  implementation-dependent mechanism for determining whether the
  unknown schema type is derived from the expected schema type. 

New:

  The given schema type may be "in-scope" (defined in the in-scope
  schema definitions), or "not in-scope" (not defined in the in-scope
  schema definitions).  An schema type that is not in-scope might be
  encountered, for example, if a source document has been validated
  using schema components in a namespace that was not imported into
  the static context. In this case, an implementation is allowed (but
  is not required) to provide an implementation-dependent mechanism
  for determining whether the not-in-scope schema type is derived from
  the expected schema type.


2. In 2.5.4 SequenceType Matching, change the example used for the
implementation-dependent mechanism, using one that involves dynamic discovery:

Old:

  For example, an implementation might maintain a data dictionary
  containing information about type hierarchies.

New:

  For example, an implementation might explore the schema that was
  used to validate a document to discover type hierarchies
  dynamically.


3. The existing definition of schema import already says that the element
declarations, attribute declarations, and type definitions are imported into
the ISSD, and does not give any exceptions. Our resolution of
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5738 asked me to add a note
clarifying that we intend this to be a transitive schema import:

Existing:


  [Definition: A schema import imports the element declarations,
  attribute declarations, and type definitions from a schema into the
  in-scope schema definitions. For each user-defined atomic type in
  the schema, schema import also adds a corresponding constructor
  function. ]

Add:

  NOTE: Unlike XML Schema's import feature, an XQuery schema import
  imports all the schema components that are in or referenced by the
  identified schema document, irrespective of their namespace.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 15 September 2009 02:00:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:40 UTC