XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML vocabulary for expressing constraints?

Steve, thank you very much for this excursion into the land of property sets! I am fascinated by the boldness of providing a generic addressing language (property sets) applicable to arbitrary data formats, without making any assumptions about the underlying data models. I suppose the key concept is to associate within-resource locations with properties, and to base within-resource navigation on property matching. And I further suppose that for each pair (format, property set) there must exist a specific software component corresponding to an XPath processor which resolves "property set expressions"  to sub resources. Yes? No?
 
I am thrilled by your statement:
"To summarize, the space you're talking about is a subspace of a larger space that includes
non-XML information, and in which XML may yet play a fantastically important integrative role.  From my personal perspective, the subspace you're thinking about is the part of the larger space that happens to be rooted in the SGML Property Set."
 
It matches my thinking in a particular way: I agree that we should discover the larger space of which XML is a sub space - a universal info space. In your thinking this may be achieved - at least conceptually - by a step of generalization: from the XML-specific property set underlying XPath (with its key properties [node-name], [children], [parent], [attributes]) to the abstract concept of property sets; and subsequent steps of instantiation, one per non-XML format to be considered. Or am I mistaken?
 
Whether feasible or not, I think this would not give us the navigational uniformity attained by "XPath everywhere". And therefore I advocate an alternative generalization: the transition from regarding XML as a syntax backed by a data model, to regarding XML as a data model backed by syntaxes one of which is XML. (Perhaps it is too much of a shortcut to call the data model XML, an alternative would be UDL - Unified Document Language). This amounts to a change of paradigm: document text (XML, HTML, CSS, JSON, CSV, SQL, Turtle, ...) is an expression whose value is an instance of the data model. The expression-oriented thinking of XPath/XQuery/XSLT would be extended and applied to the resources themselves. The reward would be a homogeneous substrate of information (homogeneous content clothed in heterogeneous syntax), supporting a uniform navigation model (XPath) and uniform processing models (XQuery, XSLT, XProc, ...).
 
Hans
 
Von: Steve Newcomb <srn@coolheads.com>
An: Hans-Juergen Rennau <hrennau@yahoo.de>; "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Gesendet: 15:54 Samstag, 14.Dezember 2013
Betreff: Re: [xml-dev] XML vocabulary for expressing constraints?

On 12/13/2013 08:25 PM, Hans-Juergen Rennau wrote:
> Steve, I would like to know what you have in mind, saying:

> "Unless I misunderstand you, Hans, SGML has always had this.  As far as I
> can see, XML still has most of it, amid a storm of deprecation by those
> who don't accept the fundamental distinction between "a homogeneous
> space of [all?] information" and a SYSTEM that provides access to some
> portion of that space."

> My position is that XML implicitly creates a global space of
> information, a space which *is* a space (= something providing for
> "location" and "movement") because of XPath. I view XML and XPath - the
> models of representation, of information content, of content navigation
> - as a single unit, facets of which are syntax, data model, navigation
> model.

I can't argue with that!

> Consequently, I am very curious in which respect you perceive a space
> whose essence is probably not XPath - because you refer to SGML. So if I
> have understood you correctly and you do perceive a space of
> information, I would like to learn more about this view.

I accept your offer to read my answer.  (How nice it is to be asked!)

Let me preface my answer by saying that serving as co-editor of HyTime
for 11 years permanently altered the way I think, for good or ill, or,
most likely, both.  (Honestly, though, I don't feel that old!)

SGML and XML both have the idea of ENTITY.  An ENTITY declaration can
declare an entity that is in XML notation, or any other notation
whatsoever, including notations that haven't been invented yet.

SGML and XML both have the idea of NOTATION.  A NOTATION declaration
establishes, in either PUBLIC terms or SYSTEM terms or both, the
existence of a notation and the fact that it may be important for anyone
who hopes to understand the document in which the declaration appears.

In SGML and XML, an ENTITY declaration can have an ATTLIST.  In such an
ATTLIST there can be a NOTATION attribute whose value refers to a
NOTATION declaration.  Thus, the notation of an entity can be declared
formally.  (Note that the word "NOTATION" is grossly overloaded.  Ugh.
I've always hated that.)

In SGML, but not in XML (as far as I know), a NOTATION declaration can
have attributes, too.

(Here ends my SGML-only discussion.  Now we come to HyTime, the stated
purpose of which, according to the chair of the committee, Charles
Goldfarb, was to test and extend SGML in such a way as to encompass all
kinds of information addressing to all kinds of information, including
both concrete and abstract music information.  For a variety of reasons
that turned out to be mostly correct, Charles regarded music as the
ultimate torture-test and therefore probably the best place to start.
And that's how I, a music theorist, educator, and science-fiction lover
with digital stars in my eyes, got involved in 1986.  Several friends
sent me copies of Charles's 1985 ANSI announcement, and I thought I'd
better pay attention.)

Now we come to the answer to your question, Hans.  HyTime uses the
feature of SGML that allows attributes to be associated with NOTATION
declarations (attributes not to be confused with the NOTATION-type
attributes which are attributes of elements and ENTITYs) to associate a
"property set" with the notation that the NOTATION declaration is
declaring.  (Sorry about that sentence.  Ugh.  Better read it again.)

You can safely think of a "property set" as a schema for a notation, but
in fact it's not *prescriptive*, it's *descriptive*.  To create a
property set is similar to creating a grid for the purpose of laying it
over a terrain in order to make the various places in the terrain more
easily addressable.  Similar, but not the same: all grids are pretty
similar to each other, but property sets are not.  Every property set is
notation-specific.  Its sole purpose is to make the components of any
instance of a NOTATION addressable.  What a component *is* depends on
one's *view* of what the components of an instance of a given notation
are, and also on which ones you consider to be worth making addressable.
In other words, to create a property set is to create a rhetoric for
addressing, or at least a substrate for such rhetorics.

Which brings us to XPath.  XPath is an nth-generation syntax derived
from the SGML Property Set (the property set for SGML notation) that is
internationally standardized in HyTime.  The SGML Property Set is also
standardized in DSSSL, the ancestor of XSLT.  So the same deep root, so
to speak, now has many fecund branches, and the story isn't over, either.

HyTime also provides an SGML syntax for using a property set to address
any component of any entity in any notation.  It's a kind of fallback --
the ultimate default way to use SGML to address anything notated
information at all, full stop, provided there's a property set for that
notation.  HyTime provides an SGML syntax for property sets, too, so
they can be created and shared at need.

XPath is, of course, far more elegant than any rhetoric provided by
HyTime, but it's also XML-specific.  (Many notations, not just XML,
should be so lucky as to have such an elegant nth-generation addressing
syntax!)

XPath and its ilk were anticipated in HyTime.  HyTime provides an SGML
syntax for associating usages of such languages with -- you guessed it
-- NOTATION declarations that would declare their syntax and properties
using -- you guessed it again -- property sets for such languages.
("It's turtles, all the way down.")

So I hope I've answered your question, Hans.  To summarize, the space
you're talking about is a subspace of a larger space that includes
non-XML information, and in which XML may yet play a fantastically
important integrative role.  From my personal perspective, the subspace
you're thinking about is the part of the larger space that happens to be
rooted in the SGML Property Set.



> One more remark. When you think about the semantics of addresses I
> suppose you mean links - one resource referencing other resources via
> links. But the space I am thinking of is not dependent on linking - it
> favours linking, as it enables the resolving of links - but it is not
> created by links. Links are but a way of using the space. The space I am
> thinking of is in the first place a navigational potential: the
> possibility to unambiguously address any single node in a worldwide
> forest, and to translate this addressability into apparent motion,
> navigation.

> Hans



_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS