[
Lists Home |
Date Index |
Thread Index
]
FWIW: http://www.topicmaps.org/xtm/index.html says this about "scope" in XTM:
scope
The extent of the validity of a topic characteristic assignment. The
context in which a name or an occurrence is assigned to a given topic, and
the context in which topics are related through associations.
The set of topics specified via a <scope> element.
See also unconstrained scope.
This specification places no constraints on how applications interpret scope.
Caveat: While I contributed to the XTM spec as one of the co-authors and as
editor and co-author of the book, I should point out that my personal view
is that there likely is no "one size fits all" and that choice of schema
should be dictated by the needs of the application. My personal quest, in
that context, is that we achieve some form of semantic interoperability
(whatever that may mean) between our applications. I think that is the
nature of the Semantic Web initiative.
Cheers
Jack
At 12:26 PM 7/29/2002 -0400, Mark Feblowitz wrote:
>Fascinating proposal. It reminds me of the factorization of decision from
>code way back in the era of rule-based systems. You can achieve an
>appropriately scoped statement of structure/behavior that is more succinct
>and, is some cases, more flexible and controllable, when the expressions
>that apply the structure/behavior are neither embedded in the data/code, nor
>rely on some implied context (e.g., that the validity of an element's
>attribute relies on the validity of the attribute in its parent,
>recursively). It might even help with the mess of cancellation semantics
>that derivation by restriction can bring.
>
>You also can more easily achieve a collection of "views" of the data, given
>different sets of scoping rules.
>
>The questions that arise are: How powerful and complex are the scoping
>statements? Can the average person make the transition from a hierarchically
>embedded definition of scope to a separable overlay of scoping rules? Will
>the rules ultimately look like an explicit replication of the implied path
>expressions and thus become all the more tedious to maintain? Or would they
>tend toward some more concise expression?
>
>Looking forward to seeing where this will lead...
>
>Mark
>
>
> -----Original Message-----
>From: Rick Jelliffe [mailto:ricko@allette.com.au]
>Sent: Monday, July 29, 2002 12:09 PM
>To: xml-dev@lists.xml.org
>Subject: [xml-dev] Scopes trial: Is there a missing piece in the XML
>puzzle?
>
>Is there a missing layer in generic tools (and standards) for XML?
>
>One way of approaching XML is as a tree of nodes of terminal
>atoms. This is more or less the view that comes out of the
>XML infoset.
>
>But another way of approaching it is as a series of scoped
>properties applying to data, where the properties of data at any
>point are all the elements and attributes of the parent and
>ancestors. This kind of scoping can be found in SVG or XSL:FO,
>for example.
>
>In the first view, the question of interest is "what are the
>properties (element name and attributes) of this content?"
>while in the second view, the question of interest is "what
>properties are in scope for this content?"
>
>The generic XML standards at W3C provide few
>generic mechanisms to work with scoped data of documents:
>perhaps XPaths ancestor-or-parent::*[1] is the only
>one that springs to mind. (Local element definitions in
>XML Schemas don't count: they say nothing about
>significance.)
>
>Looking at the various W3C specs, I think we can see that
>XML advances on HTML by allowing user-defined properties
>instead of standardized ones...except for scoped properties.
>For these, the attempt is still to get by, trying to enumerate
>a fixed specific vocabulary that can cover each case as it arises:
>xml:lang, xml:space, xmlns, xml:base and so on.
>
>The attraction of generalized markup systems is that
>we can model all sorts of data and use generic processors
>to manipulate them. But if the standards for generic
>processors (schemas, queries, transforms, etc) only
>provide one aspect, then we are left with XML documents
>which require specific tools to use.
>
>Conventional wisdom at the moment is that scoped documents
>are naturally suited to specific, optimized implementations:
>you wouldn't expect to implement SVG using a generic DOM
>for example. But I wonder if this creates a gap in our
>toolsets/standards/technology. The conventional wisdom is
>based on the current absense of any way to specificy scope.
>
>What would this missing layer look like? I am not sure. Perhaps
>it might be a simple as a simple schema language that
>sets the effectivity of elements and attributes: for example
>to say that the attribute @size applies to all of certain children
>or namespaces. Then an API could query an element's effective attributes,
>as a kind of augmented infoset very different to the PSVI of XML
>Schemas or XQuery.
>
>Or perhaps it could be done in a similar fashion to SGML's #CURRENT
>default declaration for attributes, to say that a value defaults to the last
>one
>along some axis. The API still queries in terms of attributes, but the
>implementation
>looks along the appropriate axis, providing a different view of the
>document.
>
>A schema language with some kind of scoping mechanism would allow
>a much more optimized implementation rather than relying on the
>scoping to be built into the query. (Indeed, one might say that if
>a parent does not provide any scoped properties for its child, there
>is no reason for an API to be able to locate the parent from the child.)
>
>Cheers
>Rick Jelliffe
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://lists.xml.org/ob/adm.pl>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://lists.xml.org/ob/adm.pl>
|
