Hi Folks,

I created a tool that makes it easier for you to extract information 
out of XML Schemas.

Here is the tool:

http://www.xfront.com/XML-Schema-Tool-for-Easy-Information-Extraction/index.html  

Motivation for the tool:

Here are a few examples of queries that I've needed to perform
on schemas in the past:

- What are all the elements and attributes that are declared
  to be of type xs:QName (or xs:string, or xs:gYear, etc.)?

- For simpleType A, what are its applicable facets? (Take
  into account the facets in all its ancestor simpleTypes)

- How many element declarations are in the schema? How many
  complexType definitions? simpleTypes? attributes?

- How many lines of schema code are there?

With my tool it is easy to get answers to those questions.

Without this tool, it can be difficult to get the info you desire
from XML Schemas. Here are a few reasons for the difficulty:

1. The schema may be scattered over multiple files. So you have 
   to search through multiple files to find the info you want.

2. A simpleType may be part of a long chain of restrictions. And the
   simpleTypes may be scattered over multiple files. That
   makes it difficult to know exactly what is the net value space 
   for the simpleType.

3. Likewise a complexType may be part of a long chain of derive-by-
   extensions and derive-by-restrictions. And the complexTypes
   may be scattered over multiple files. That makes it difficult
   to know exactly what is the final set of elements and attributes
   in a complexType.

4. An element may be substituted. So, many different elements may
   be possible at a certain point in a schema.

5. Consider an element declaration with a type attribute. The type
   definition could be located in many places: in the document that
   the element declaration is located in, in a document that it
   includes or imports, or one that they include or import. It 
   could be in the document that included the document that
   contains the element declaration. And many more places. Ouch!

6. The elements and attributes in a no-namespace schema are
   part of one namespace when they are included by a schema with
   targetNamespace A and another namespace when they are included 
   by a schema with targetNamespace B.

/Roger

A quick reminder: tomorrow is the deadline for the early-registration discount 
for the XForms and XQuery courses in June. 

--CMSMcQ

[This announcement will be of interest primarily to those living
in or near Washington, DC, or planning to travel there for the
Joint Conference on Digital Libraries this June, and to those
interested in XForms and/or XQuery training.  If you know others
who meet that description, please forward this announcement to
them.  Thanks!  Others may stop reading now.]

Black Mesa Technologies is pleased to announce two hands-on
introductory courses, one on XForms and one on XQuery, to take place
in June 2012, in Rockville, Maryland (immediately before and after the
ACM/IEEE-CS Joint Conference on Digital Libraries on 10-14 June 2012
at George Washington University in Washington, DC).


INTRODUCTION TO XFORMS FOR XML USERS

  8-9 June 2012, 9:30 - 5:30
  http://www.blackmesatech.com/2012/06/xforms/

  XForms allows you to develop vocabulary- and task-specific editors
  which require less training and provide better task-specific
  support than full XML editors; domain experts can thus examine and
  modify XML encoding mor easily, and routine tasks can be performed
  more quickly and reliably.

  This course introduces XForms as a technology for building
  special-purpose XML editors with focused functionality and
  correspondingly simple user interfaces. XForms is built on the
  model / view / controller idiom, in which the 'model' is a set of
  XML documents, the 'view' is specified using XHTML and XForms
  widgets, and the 'controller' takes the form of declarative links
  between widgets and elements or attributes in the XML documents.


XQUERY FOR DOCUMENTS

  15-16 June 2012, 9:30 - 5:30
  http://www.blackmesatech.com/2012/06/xquery/

  This course introduces XQuery as a flexible language for working
  with natural-language documents (books, prose, verse, drama,
  correspondence, historical documents, articles, legislation, etc.)
  encoded in XML. The focus is on the application of XQuery to
  textual material with complex and variable structure, as opposed to
  the typically simpler, more regular structures of data-oriented
  XML.  The course will cover XPath location paths, atomic values,
  sequences of values, the XDM data model, FLWOR expressions,
  function declarations, regular expressions and string manipulation,
  collections, and the full-text extensions to XQuery.


LOGISTICS

The courses will be held Friday and Saturday, 8-9 June 2012 (XForms)
and Friday and Saturday, 15-16 June 2012 (XQuery), from 9:30 a.m. to
5:30 p.m. at

  Mulberry Technologies, Inc.
  17 West Jefferson St., Suite 207
  Rockville, MD 20850

For other logistical information, see 

   http://www.blackmesatech.com/2011/06/xforms
   http://www.blackmesatech.com/2011/06/xquery

Thanks to Mulberry Technologies for hosting the courses.

Other courses that may be relevant to potential attendees (XML Basics,
Schematron, XSLT/XPath Basics, and XSL-FO) are offered in the same
venue on earlier days; see Mulberry Technologies' list of upcoming
classes at

 http://www.mulberrytech.com/services/classes/upcoming.html


REGISTRATION / INFO

To reserve a space, to register, or to ask for more information,
please send email to info@blackmesatech.com or call us at
505/747-4224.


FUTURE ANNOUNCEMENTS

[If you'd like to receive announcements of future courses (etc.) by
email, go to http://lists.blackmesatech.com/blackmesatech-announce-l/
to sign up for the Black Mesa Technologies announcement list.]


-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

XMLmind is happy to announce the version 5.2.1 of XMLmind XML Editor.
     _____________________________________________

XMLmind XML Editor Personal Edition v5.2.1 can be downloaded from
http://www.xmlmind.com/xmleditor/download.shtml

Professional Edition users, please upgrade using this form:
http://www.xmlmind.com/store/download.php

(The above form is usually accessed through
http://www.xmlmind.com/xmleditor/upgrade.html.)
     _____________________________________________

XMLmind XML Editor v5.2.1 (May 9, 2012):
----------------------------------------

New "Easy Selection Mode".

Several other enhancements (sort table rows,
preview converted document, etc).

Some bug fixes.
     _____________________________________________

"Easy Selection Mode" Primer:
http://www.xmlmind.com/xmleditor/_tutorial/easyselect_primer/index.html

"Easy Selection Mode" Screencast:
http://www.xmlmind.com/xmleditor/_tutorial/easyselect_primer/video/easyselect_primer.html

More information:
http://www.xmlmind.com/xmleditor/changes.html

Graham Hannington scripsit:

> I am aware of http://html5.validator.nu/ and its associated 
> http://about.validator.nu/, and I am learning (for example, about Relax 
> NG).

RELAX NG supports wildcard element and attribute names of the form *,
prefix:*, and *:*, but not of the form data-*, unfortunately

-- 
Principles.  You can't say A is         John Cowan <cowan@ccil.org>
made of B or vice versa.  All mass      http://www.ccil.org/~cowan
is interaction.  --Richard Feynman

Preamble (if you prefer, skip to the "Question(s)" heading):

I am lagging (years) behind in my knowledge of HTML5 - I have been fixated 
on XHTML 1.0 Strict compliance - but I am trying to catch up.

Someone (thank you, Chris!) recently pointed out to me that HTML5 allows 
attributes named data-* (for example, data-atlassian-layout).

I had observed the use of data-* attributes by various applications, but 
the news of the inclusion of these attributes in the HTML5 spec frankly 
blindsided me (I did say I was far behind).

As mentioned in a recent thread on this mailing list, I have developed a 
DTD and XSDs (W3C XML Schema 1.0) for an XML vocabulary that consists of a 
combination of:
- Proprietary elements and their attributes, and
- Elements that have the same name as elements in XHTML (so far, 
exclusively from XHTML 1.0; and - until now, hence this email - with 
attributes that are a subset of the attributes allowed in XHTML 1.0 
Strict).

This XML vocabulary is evolving. The developers have begun using a 
data-atlassian-layout attribute on div elements.

I have added corresponding explicit definitions for this new attribute to 
the DTD and XSD (for that particular target namespace). But it's raised 
some questions in my mind.

Question(s):

It occurs to me that HTML5 allowing data-* attributes means that any given 
XHTML5 document instance cannot be validated using a fixed, standard XML 
DTD or W3C XML Schema 1.0 (or 1.1, for that matter) document (XSD). 
Because (to my knowledge), DTDs and XSDs require you to explicitly specify 
attribute names; you cannot, in these particular schema languages, define 
attributes with wildcarded names. If an XHTML5 document instance contains 
data-* attributes, then, if you want to use a DTD or an XSD to validate 
it, the DTD or XSD must explicitly define those particular data-* 
attribute names (data-this, data-that; not just data-*). Correct?

Effectively the same point/question, stated slightly differently... With 
XHTML 1.0, one could use a standard DTD/XSD from W3C, unmodified, to 
validate all XHTML 1.0 document instances. It seems to me that you will 
not be able to use a single, standard DTD/XSD from W3C to validate all 
XHTML5 document instances. You'll need to define any data-* attributes. 
Correct?

I imagine that the reaction of many readers will be (a more erudite 
version of) "Well, d'uh! Have you been living under a rock?" I've Googled, 
but have so far not found any rock-solid ;-) answers to this specific 
issue.

Are there any other aspects of XHTML5 that introduce new* problems for 
validating with DTD/XSDs?

* Specifically, compared to validating XHTML 1.0 with DTD/XSDs? (I do not 
seek an answer that covers *all* of the shortcomings of these two schema 
languages - such as the inability to describe various kinds of constraints 
- although I understand that some of these shortcomings are likely to be 
closely tied to the problems with validating XHTML5 versus validating 
XHTML 1.0.)

I am aware of http://html5.validator.nu/ and its associated 
http://about.validator.nu/, and I am learning (for example, about Relax 
NG).

Graham Hannington
Perth, Western Australia

Fundi Software Pty Ltd  2012  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

In XSD 1.0 you can allow these attributes (and many others of course) by 
use of an <xs:anyAttribute> wildcard.

In XSD 1.1 you can then constrain the attribute names that match the 
wildcard using assertions.

It has always been the case, of course, that not all rules in the XHTML 
specification are capable of being expressed in XSD. The same applies to 
most other vocabularies (including XSD itself).

Michael Kay
Saxonica

On 05/05/2012 14:59, Graham Hannington wrote:
> Preamble (if you prefer, skip to the "Question(s)" heading):
>
> I am lagging (years) behind in my knowledge of HTML5 - I have been fixated
> on XHTML 1.0 Strict compliance - but I am trying to catch up.
>
> Someone (thank you, Chris!) recently pointed out to me that HTML5 allows
> attributes named data-* (for example, data-atlassian-layout).
>
> I had observed the use of data-* attributes by various applications, but
> the news of the inclusion of these attributes in the HTML5 spec frankly
> blindsided me (I did say I was far behind).
>
> As mentioned in a recent thread on this mailing list, I have developed a
> DTD and XSDs (W3C XML Schema 1.0) for an XML vocabulary that consists of a
> combination of:
> - Proprietary elements and their attributes, and
> - Elements that have the same name as elements in XHTML (so far,
> exclusively from XHTML 1.0; and - until now, hence this email - with
> attributes that are a subset of the attributes allowed in XHTML 1.0
> Strict).
>
> This XML vocabulary is evolving. The developers have begun using a
> data-atlassian-layout attribute on div elements.
>
> I have added corresponding explicit definitions for this new attribute to
> the DTD and XSD (for that particular target namespace). But it's raised
> some questions in my mind.
>
> Question(s):
>
> It occurs to me that HTML5 allowing data-* attributes means that any given
> XHTML5 document instance cannot be validated using a fixed, standard XML
> DTD or W3C XML Schema 1.0 (or 1.1, for that matter) document (XSD).
> Because (to my knowledge), DTDs and XSDs require you to explicitly specify
> attribute names; you cannot, in these particular schema languages, define
> attributes with wildcarded names. If an XHTML5 document instance contains
> data-* attributes, then, if you want to use a DTD or an XSD to validate
> it, the DTD or XSD must explicitly define those particular data-*
> attribute names (data-this, data-that; not just data-*). Correct?
>
> Effectively the same point/question, stated slightly differently... With
> XHTML 1.0, one could use a standard DTD/XSD from W3C, unmodified, to
> validate all XHTML 1.0 document instances. It seems to me that you will
> not be able to use a single, standard DTD/XSD from W3C to validate all
> XHTML5 document instances. You'll need to define any data-* attributes.
> Correct?
>
> I imagine that the reaction of many readers will be (a more erudite
> version of) "Well, d'uh! Have you been living under a rock?" I've Googled,
> but have so far not found any rock-solid ;-) answers to this specific
> issue.
>
> Are there any other aspects of XHTML5 that introduce new* problems for
> validating with DTD/XSDs?
>
> * Specifically, compared to validating XHTML 1.0 with DTD/XSDs? (I do not
> seek an answer that covers *all* of the shortcomings of these two schema
> languages - such as the inability to describe various kinds of constraints
> - although I understand that some of these shortcomings are likely to be
> closely tied to the problems with validating XHTML5 versus validating
> XHTML 1.0.)
>
> I am aware of http://html5.validator.nu/ and its associated
> http://about.validator.nu/, and I am learning (for example, about Relax
> NG).
>
> Graham Hannington
> Perth, Western Australia
>
> Fundi Software Pty Ltd  2012  ABN 89 009 120 290
>
>
> This message has been scanned for malware by Websense. www.websense.com
>
> _______________________________________________________________________
>
> 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
>
>

Hi Graham,

> <uri name="http://www.atlassian.com/schema/confluence/4/ac/"
uri="confluence.xsd"/>

in XML ValidatorBuddy you have a single command to add any W3C schema with a
target namespace to the XML catalog to create such an <uri> entry for any
following validation. There is also no need to provide a schemaLocation
attribute in the XML instance. The schema mapping takes place when the
namespace is used.

I guess this is close to how you would expect it.

Kind regards
Clemens Uhlenhut
http://www.xml-tools.com

 

________________________________________
From: Graham Hannington [mailto:graham_hannington@fundi.com.au] 
Sent: Freitag, 20. April 2012 09:33
To: xml-dev@lists.xml.org
Subject: Re:  If I want to use catalogs for XSDs, must document
instances contain a schemaLocation?

Liam,

Thank you very much for your quick and informative response, it's much
appreciated.

Regarding your statement:

> doing it based on namespace URIs would not be a good way

I hope you don't think I'm splitting hairs; I sincerely want to understand
this...

Here's how I think it works. When an XML document instance contains the
following schemaLocation attribute:

xsi:schemaLocation="http://www.atlassian.com/schema/confluence/4/ac/confluen
ce.xsd"

my understanding is that catalog-aware XML applications (such as XMLSpy)
look at the first part of that attribute value*, match it with the value of
the name attribute of the following uri element in the catalog:

<uri name="http://www.atlassian.com/schema/confluence/4/ac/"
uri="confluence.xsd"/>

and then load the XSD referred to by the uri attribute
(uri="confluence.xsd").

* From the "XML Schema Part 0: Primer Second Edition"
(http://www.w3.org/TR/xmlschema-0/#schemaLocation)

> The schemaLocation attribute value consists of one or more pairs of URI
references, separated by white space. The first member of each pair is a
namespace name

That is, although an XML application isn't doing it based on the value of
xmlns: attributes (as you say: "Neither should it."), it seems to me that it
*is* doing it based on namespace URIs (specifically, the first member of
each pair of URI references in a schemaLocation attribute value).

Am I just splitting hairs, or am I (as I suspect) missing a deeper point
here?

Also this:

> There is no direct mapping between namespace URIs and Schema documents

Now - with apologies, I do not mean to try your patience or waste your time;
I do read and re-read the related W3C documents, and some of it has sunk in
- I really think I am missing a deeper point here, because, as described
above, I think a direct mapping between a namespace URI and a schema
document is exactly the process that I've just described above, and is
exactly what that uri element in a catalog does:

<uri name="http://www.atlassian.com/schema/confluence/4/ac/"
uri="confluence.xsd"/>

If this uri element does not directly map a namespace URI to a schema
document, what does it do?

Finally:

> the relationship is that Schema documents may define elements associated
with one or more namespace URIs.

I'm not saying that you're asserting otherwise, but I want to confirm that
my current understanding in this area is correct. I think that one schema
document (XSD; a single .xsd file) can define elements associated with only
one namespace URI (its target namespace). An XSD (again, I mean,
specifically, a single .xsd file) can use <import> elements to import
element definitions associated with other namespace URIs, but that is not
quite the same as one XSD defining elements associated with multiple
namespace URIs. An XML vocabulary that involves more than one namespace
cannot be defined in a single .xsd file. Am I correct? If not, could you
please point me to, or provide, an example of a single XSD that defines
elements associated with more than one namepace URI? (The XSD mentioned in
my examples, confluence.xsd - which I wrote - uses import elements to refer
to two other XSDs.)

I hope you don't think that I'm challenging you. That's not my intention. I
am sincerely grateful for your initial reply. Having gained your attention
(and noting your signature line), I am, without wanting to take up too much
of your time, hoping to learn more. And I am prepared to publicly expose my
ignorance to do so :-).

Graham Hannington
Perth, Western Australia
Fundi Software Pty Ltd 2011 ABN 89 009 120 290
=
This message has been scanned for malware by Websense. www.websense.com

Dear all,

once more, we are proud to announce a new version of BaseX!
And once more, we can provide you with a whole bunch of
new features:

* Our value indexes now support string-based range queries:
 http://docs.basex.org/wiki/Indexes#Value_Indexes
 A big thank you to our sponsors who made this possible!

* Our new XQJ API is based on Charles Foster's implementation.
 It fully utilizes the client/server architecture:
 http://xqj.net/basex

* Import of XQuery modules has been simplified:
 http://docs.basex.org/wiki/Repository

* Simplified invocation of Java code from XQuery:
 http://docs.basex.org/wiki/Java_Bindings

* Full support for the XQuery 3.0 Regular Expressions syntax:
 http://www.w3.org/TR/xpath-functions-30/#regex-syntax

* Updating functions can now return values:
 http://docs.basex.org/wiki/Database_Module#db:output

* Unified handling of document and database URIs:
 http://docs.basex.org/wiki/Databases#Access_Resources

* Pinning of opened database replaced by filesystem locking:
 http://docs.basex.org/wiki/Transaction_Management#Locking

* REST, RESTXQ, WebDav: concurrency issues fixed

As usual, we are looking to your feedback. Have fun,

Christian
BaseX Team
http://basex.org

On 25/04/2012 16:40, John Cowan wrote:
> Greg Hunt scripsit:
>
>> To the extent that ISO is a culture all to itself (the ISO definition of a
>> week does not align with traditional Christian, Islamic or Jewish calendars
>> but does seem to be well suited for the Western working week), Mike's point
>> about the start, definition and numbering of weeks seems to be reinforced
>> by your comment.
> Well, no doubt.  But the fact that YYYY-MM-DD is a relatively uncommon
> way of writing dates (mostly found in East Asia) didn't stop ISO from
> standardizing it or XML Schema datatypes from adopting it.  So "Ways of
> conceptualizing the week are diverse" is not an argument against accepting
> the ISO way, any more than "Ways of writing the date are diverse" is.
The use of a numeric day, month, and year to represent a day in the 
calendar is very common around the world, and all that ISO did was to 
define a machine-readable notation for expressing the day, month, and 
year for use in software-to-software communication. Wider adoption of 
that format for human consumption came later, and was not part of the 
original intent of the ISO standard.

As for week numbers, as I said before, it's all a question of how you 
decide where to draw the line. As with proposals to add things to the 
XPath function library it's very hard to find a convincing objective 
test for what should go in and what shouldn't. If you shout loud enough, 
and give the impression that you're not the only person shouting, then 
people will eventually put it in to keep you quiet - lots of 
inappropriate things are in the XSD specification for that reason.

Michael Kay
Saxonica

Greg Hunt scripsit:

> To the extent that ISO is a culture all to itself (the ISO definition of a
> week does not align with traditional Christian, Islamic or Jewish calendars
> but does seem to be well suited for the Western working week), Mike's point
> about the start, definition and numbering of weeks seems to be reinforced
> by your comment.

Well, no doubt.  But the fact that YYYY-MM-DD is a relatively uncommon
way of writing dates (mostly found in East Asia) didn't stop ISO from
standardizing it or XML Schema datatypes from adopting it.  So "Ways of
conceptualizing the week are diverse" is not an argument against accepting
the ISO way, any more than "Ways of writing the date are diverse" is.

It's true that Zawinski's Snowclone says: "People say, 'There are N
ways to do things.  I know!  We'll create an international standard!'
Now there are N + 1 ways of doing things."  But examples like ASCII and
Unicode show that if you want a while, and the standard is really good
enough for its time, the other N ways of doing things become marginalized
and may even disappear: who uses Baudot or Flexowriter codes, or American
Morse, today?

-- 
Said Agatha Christie / To E. Philips Oppenheim  John Cowan
"Who is this Hemingway? / Who is this Proust?   cowan@ccil.org
Who is this Vladimir / Whatchamacallum,         http://www.ccil.org/~cowan
This neopostrealist / Rabble?" she groused.
        --George Starbuck, Pith and Vinegar

Jirka Kosek writes:

> Might be I'm not understanding you correctly Liam, but IMHO namespace
> URI is perfect way to *indirectly* say where the schema is located.

Indeed the W3C XML Schema specification says this explicitly [1]:

 The author of a document uses namespace declarations to indicate the
 intended interpretation of names appearing therein; it is possible
 but not guaranteed that a schema is retrievable via the namespace
 name.

> Good XML application support mapping file where namespace URI can be
> mapped to schema which should be used for validation. Graham should
> inspect his tool whether it provides such facility. In oXygen there is
> Document Type Association option for this, Emacs+nxml support
> locatingRules, NVDL can be used for this as well.

XSV supports RDDL at the namespace URI for this purpose, and gives
user control on whether namespace URIs are dereferenced or not.

ht

[1] http://www.w3.org/TR/xmlschema11-1/#schema-loc
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

While the W3C Guidance is useful, it may not be what determines what and how
Victor does this. Where and for whom Victor is writing the specification
does. 

I have prepared several schemas as part of OASIS specifications. Those
schemas followed OASIS rules for naming and location and support of RDDL.
Other groups have their own rules. Within the schemas mentioned above, there
were specific references to UN CEFACT schemas and to OGC schemas, each
addressable, but with slightly different rules. They also referenced an
older namespace with a URN initially defined in an RFC.

In short, there is no universal "correct" way to do this. If you are
preparing a Standard, then the Standards Development Organization (SDO) may
well have explicit requirements and expectations.


"If something is not worth doing, it`s not worth doing well" - Peter Drucker

Toby Considine
TC9, Inc
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  
Email: Toby.Considine@gmail.com
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com



-----Original Message-----
From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] 
Sent: Tuesday, April 24, 2012 4:46 AM
To: Victor Porton
Cc: xml-dev@lists.xml.org
Subject: Re:  If I want to use catalogs for XSDs, must document
instances contain a schemaLocation?

Victor Porton writes:

> I am writing a standard about what should be located at namespace URLs.

The W3C has already published guidance on this topic: you should look at the
TAG finding

 Associating Resources with Namespaces [1]

ht

[1] http://www.w3.org/2001/tag/doc/nsDocuments/
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/  [mail from me
_always_ has a .sig like this -- mail without it is forged spam]

_______________________________________________________________________

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

Victor Porton writes:

> I am writing a standard about what should be located at namespace URLs.

The W3C has already published guidance on this topic: you should look
at the TAG finding

 Associating Resources with Namespaces [1]

ht

[1] http://www.w3.org/2001/tag/doc/nsDocuments/
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

23.04.2012, 23:53, "G. Ken Holman" <gkholman@CraneSoftwrights.com>:
> I hope this is considered helpful, especially if
> you've not heard of RDDL before.

Yes, I've not hear about RDDL before. I've written a note that I should integrate my standard with RDDL.

But as of now I use my free time for abstract mathematical research and am going to work with XML in an indefinite future.

-- 
Victor Porton - http://portonvictor.org

23.04.2012, 23:28, "Liam R E Quin" <liam@w3.org>:
> On Mon, 2012-04-23 at 12:31 +0200, Jirka Kosek wrote:
>
>> Å¡Might be I'm not understanding you correctly Liam, but IMHO namespace
>> Å¡URI is perfect way to *indirectly* say where the schema is located.
>>
>> Å¡Good XML application support mapping file where namespace URI can be
>> Å¡mapped to schema which should be used for validation.
>
> Yes, that aspect is fine. Blindly dereferencing the namespace and
> expecting to find a schema there is what I was saying is not fine.

I am writing a standard about what should be located at namespace URLs.

This should contain not only schemas (of any kind) but also rules for transformations between different namespaces.

I think this is an important standard (when I will release a good draft), but we need work on its promotion to become an agreed industry standard. Your help to promote it could be essential.

http://freesoft.portonvictor.org/binaries/Namespace_Semantic.doc

>> Å¡In theory on namespace URI could reside RDDL document which can point to
>> Å¡XML schema, but past experience with heavy loaded network resources
>> Å¡(XHTML DTDs) shows that's not wise to depend on such approach in an
>> Å¡application.
>
> The XML Plenary failed to get consensus on whether it was acceptable to
> define anything at a namespace URI, or even if it was OK to try to
> dereference them.
>
> If applications did start, you're right, W3C would have to block the
> ones on our servers, as we have to do for the DTDs and XSD files.


-- 
Victor Porton - http://portonvictor.org

At 2012-04-23 23:44 +0300, Victor Porton wrote:
>23.04.2012, 23:28, "Liam R E Quin" <liam@w3.org>:
> > On Mon, 2012-04-23 at 12:31 +0200, Jirka Kosek wrote:
> >
> >> šMight be I'm not understanding you correctly Liam, but IMHO namespace
> >> šURI is perfect way to *indirectly* say where the schema is located.
> >>
> >> šGood XML application support mapping file where namespace URI can be
> >> šmapped to schema which should be used for validation.
> >
> > Yes, that aspect is fine. Blindly dereferencing the namespace and
> > expecting to find a schema there is what I was saying is not fine.
>
>I am writing a standard about what should be located at namespace URLs.

Why compete with RDDL?  http://www.rddl.org

With RDDL you simultaneously get both human 
readable and machine readable information about 
the XML vocabulary.  RDDL attributes are simply added to XHTML pages.

OASIS Open uses the RDDL specification and here 
are the namespace URI pages for two of the 
standard XML vocabularies I've worked on in the code list technical committee:

   http://docs.oasis-open.org/codelist/ns/genericode/1.0/
   http://docs.oasis-open.org/codelist/ns/ContextValueAssociation/1.0/

I've published a free stylesheet to help people 
write RDDL pages for their namespace URIs:

   http://www.CraneSoftwrights.com/resources/#showrddl

There is no standard layout for an XHTML/RDDL 
page ... it can be whatever you want and you can 
point to whatever resources you want.  It is all 
useful information and both human and machine 
discoverable through the namespace URI.

>This should contain not only schemas (of any 
>kind) but also rules for transformations between different namespaces.

It shouldn't contain anything but pointers to all 
of the possible things that might be of interest 
to users of the XML vocabulary.

>I think this is an important standard (when I 
>will release a good draft), but we need work on 
>its promotion to become an agreed industry 
>standard. Your help to promote it could be essential.

I think promoting something that competes with an 
established practice doesn't help the existing community of users.

I hope this is considered helpful, especially if 
you've not heard of RDDL before.

. . . . . . . . . . Ken

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- May 2012
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/x/
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

On Mon, 2012-04-23 at 12:31 +0200, Jirka Kosek wrote:

> Might be I'm not understanding you correctly Liam, but IMHO namespace
> URI is perfect way to *indirectly* say where the schema is located.
> 
> Good XML application support mapping file where namespace URI can be
> mapped to schema which should be used for validation.

Yes, that aspect is fine. Blindly dereferencing the namespace and
expecting to find a schema there is what I was saying is not fine.

> In theory on namespace URI could reside RDDL document which can point to
> XML schema, but past experience with heavy loaded network resources
> (XHTML DTDs) shows that's not wise to depend on such approach in an
> application.

The XML Plenary failed to get consensus on whether it was acceptable to
define anything at a namespace URI, or even if it was OK to try to
dereference them.

If applications did start, you're right, W3C would have to block the
ones on our servers, as we have to do for the DTDs and XSD files.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Hi Liam,

Me again :-).

> 
> >   If the advertisement
> > in the @xml:type does not match one of the client's 
> capabilities, no 
> > request to that xml:href URI will ever be made, saving the network 
> > bandwidth, and the server the effort of replying to a 
> request it cannot honour.
> 
> But you don't know in advance. The xml:type is just going to 
> be wrong most of the time.

It's advisory.  If it's important, it's not going to be wrong.  
Browsers seem to only care about the @rel="stylesheet" bit, and don't
parse @type.  So you can leave it out in that case.  But if that 
bit of metadata was used to disambiguate xslt from css requests, for example,
it would be more important to the author to get and keep right.  That's
what it's for: to help drive client state. 

I will admit that there's not much literature available from google on
the use of this attribute.  I will do a bit more digging.


> 
> > > I'm personally interested in typed links, where the types are 
> > > rhetorical in nature - e.g. "supports", "disagrees", or express 
> > > other relationships.
> > 
> > This is the relationship of the referenced resource to the current 
> > client state, and is supposed to be stored in @xml:rel, which is 
> > similar to atom:link@rel or html:link@rel.  *I* think you 
> need _both_ 
> > @xml:rel and @xml:type to qualify as a typed link.
> We'll have to agree to differ.

Seems that we agree on 2/3 attributes so far ;-).  I will keep working
on that third one...

> 
> [...]
> > However, without the advertisement found in @xml:type, no 
> such crawler 
> > is practical, because you would have to crawl _everything_ to 
> > determine what is/is not a document you can analyze.
> 
> You have to do that anyway if you want to be complete.
> 
> Suppose you are interested in SVG images. So you don't crawl 
> to an XML DocBook document. But the illustrations in that 
> DocBook document were in SVG. So you lose.
> 
> [...]
> > > The client can *always* send an Accept header saying they 
> prefer PNG 
> > > to SVG. (content negotiation is of course different from "HTTP 
> > > OPTIONS")
> > 
> > Yes.  But again, the advertisement in the metadata is a hint to the 
> > client of what to enter into negotiation with.
> 
> When you write the document you don't know what formats the 
> client will prefer, unless you write for only one piece of software.
> 
> So the document is the wrong place for it.

OK, one can produce an image index by crawling html pages and
finding linked images; text/html is a rich source of links to image/*.
image/svg is a usually a separate media type from text/html,
but it is encompassed and overshadowed by text/html when it is produced in-line.

If you crawled an xml-based media type, you would likely need the xml:type
hint to help you out, in particular where the @xml:rel was not a differentiator,
see the discussion of <link rel="stylesheet".../> above.

> 
> 
> [...]
> 
> > > Is the problem the namespace declaration? There was talk 
> about that 
> > > a year or two ago on xml-dev, about reforming namespaces, but 
> > > there's too much XML 1.0 inertia to make it easy.
> > 
> > Yes, it is one of the problems.  But I don't think it is the 
> > declaration so much as the fact that users have to declare it and 
> > clients have to verify that it matches.  The xml:href, xml:rel and 
> > xml:type _strings_ can be found without understanding namespaces, I 
> > think.  Maybe I'm trying to skirt around the issue of 
> namespaces, but 
> > I think using the implicit xml namespace is appropriate because web 
> > hyperlinking is a top priority use case for xml.
> 
> I think that's very subjective - I'd rather add xml:include 
> and xsi:type myself. But that was why I wrote the 
> "unobtrusive namespace" stuff, so you could have (in effect) 
> a predeclared list of namespces. It didn't fly, though.

OK, I reflected on this a bit, and I just read the "Automatic Namespaces" paper
you gave at Balissage 2009 (sorry!).

First, the problem with having links in some arbitrary namespace is that they can be
syntactically re-assigned ie. xlink: could just as easily read linkinglanguage:,
or an empty string.  So links can't be easily recognized.  Since xml: can not be reassigned,
xml:href always means xml:href, and xml: always has to be present.  So links 
will always be recognised.

Automatic namespaces don't change the fact that the href can be in any
namespace as defined by the profile in the xml:ns reference document.

BTW I think the concept of automatic namespaces is compatible with the concept
of a 'profile' link relation, which is being promoted by Erik Wilde over
on rest-discuss.
http://dret.typepad.com/dretblog/2012/03/resource-profiles.html

While Erik's proposal is for a link relation 'profile' which has an associated URI
which is abstract (ie. not necessarily dereferenceable), your automatic namespaces xml:ns
reference actually associates an xml file describing the profile of an xml file
encoded according to a similar concept.

xml:ns="http://example.org/myautons.xml"

would map nicely to

<link xml:rel="profile" xml:href="http://example.org/myautons" xml:type="application/xml;type=autonamespace"/>
<link xml:rel="profile" xml:href="http://example.org/myautons" xml:type="application/json;type=autonamespace"/>

I think the notion of a profile, and the notion of automatic namespaces both need to
consider the MIME media type with a bit more priority.  In other words,
the concept of a profile and that of automatic namespaces are
working in the same space as the role of MIME media type.  The MIME media
type needs to be known to an application in order to process files of that
media type.  Just like an application must be built to process UTF-8 characters
instead of US-ASCII,  an application must be written to process text/html
with in-line svg. Whether there are namespace prefixes or not is a programming
detail, and one which I as an xslt programmer have been happy to live with.
HTML/js programmers, not so much!  But the point remains that it is the
media type that is the final descriptor of the expected content, regardless
of the namespaces involved.  And having a link to a profile from within the
target document is too late a la either of the above equivalent examples - 
it needs to be advertised and negotiated prior to pulling in the document, 
otherwise you get wasted bandwidth etc.  See REST.


> 
> 
> > > Hmm, I have not seen atom:link in use outside atom, I'd be 
> > > interested to learn more about that and see examples.
> > 
> > 
> https://developers.google.com/kml/documentation/kmlreference#atomlink
> > http://www.rssboard.org/rss-profile#namespace-elements-atom-link
> 
> The kml one is interesting, are you suggesting Google Earth 
> uses atom in some way?

Not very well, IMHO.  For example, it does not use atom:link@rel="next",
which would be a nice feature for paging data RESTfully.

> 
> The rssboard one is just atom and rss, which is where atom started ;)

I guess it came full circle, adding standardized links to RSS.  The point
is there is a great need for that standardization.


> you're in Ottawa I'm only 3½ hours' drive away :-)

Well if you're getting the same snow we're getting today, you have my sympathy!

Cheers,
Peter

On 20.4.2012 8:00, Liam R E Quin wrote:

> The answer is that you have to tell your schema processor how to find he
> schemas, and that schemaLocation attributes are one way, but not the
> only way - the program might have another way to do it - but doing it
> based on namespace URIs would not be a good way.

Might be I'm not understanding you correctly Liam, but IMHO namespace
URI is perfect way to *indirectly* say where the schema is located.

Good XML application support mapping file where namespace URI can be
mapped to schema which should be used for validation. Graham should
inspect his tool whether it provides such facility. In oXygen there is
Document Type Association option for this, Emacs+nxml support
locatingRules, NVDL can be used for this as well.

In theory on namespace URI could reside RDDL document which can point to
XML schema, but past experience with heavy loaded network resources
(XHTML DTDs) shows that's not wise to depend on such approach in an
application.

				Jirka

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

OpenPGP digital signature

Michael Kay scripsit:

> It's worth noting that whereas there is some kind of consensus on
> when seconds, minutes, hours, days, months, and years start and end
> (subject to timezone issues), there is no consensus on when a week
> starts or ends. 

There is, however, an ISO standard: weeks begin on Monday, and the first
week of the year is the week containing the first Thursday in January.
Thus 2005-01-01, a Saturday, is synonymous with 2005-W53-6, the sixth
day of the 53rd and last week of 2004.

Note that XSD time does not include leap seconds, which means that the
XSD 1.1 value space for durations contains <second, month> pairs.
There are a fixed number of seconds in a minute, hour, and day, and a
fixed number of months in a year.

-- 
"Repeat this until 'update-mounts -v' shows no updates.         John Cowan
You may well have to log in to particular machines, hunt down   cowan@ccil.org
people who still have processes running, and kill them."

On Fri, 2012-04-20 at 13:06 +0000, Rushforth, Peter wrote:
[...]
> My understanding of content negotiation is that the client sends an Accept
> header with a list of weighted preferences.

Yes.

>   If the advertisement
> in the @xml:type does not match one of the client's capabilities,
> no request to that xml:href URI will ever be made, saving the network bandwidth,
> and the server the effort of replying to a request it cannot honour.

But you don't know in advance. The xml:type is just going to be wrong
most of the time.

> > I'm personally interested in typed links, where the types are 
> > rhetorical in nature - e.g. "supports", "disagrees", or 
> > express other relationships.
> 
> This is the relationship of the referenced resource to the current client state,
> and is supposed to be stored in @xml:rel, which is similar to atom:link@rel
> or html:link@rel.  *I* think you need _both_ @xml:rel and @xml:type to qualify
> as a typed link.
We'll have to agree to differ.

[...]
> However, without the advertisement found in @xml:type, no such crawler is practical,
> because you would have to crawl _everything_ to determine what is/is not
> a document you can analyze.

You have to do that anyway if you want to be complete.

Suppose you are interested in SVG images. So you don't crawl to an XML
DocBook document. But the illustrations in that DocBook document were in
SVG. So you lose.

[...]
> > The client can *always* send an Accept header saying they 
> > prefer PNG to SVG. (content negotiation is of course 
> > different from "HTTP OPTIONS")
> 
> Yes.  But again, the advertisement in the metadata is a hint to the
> client of what to enter into negotiation with.

When you write the document you don't know what formats the client will
prefer, unless you write for only one piece of software.

So the document is the wrong place for it.


[...]

> > Is the problem the namespace declaration? There was talk 
> > about that a year or two ago on xml-dev, about reforming 
> > namespaces, but there's too much XML 1.0 inertia to make it easy.
> 
> Yes, it is one of the problems.  But I don't think it is the
> declaration so much as the fact that users have to declare it and
> clients have to verify that it matches.  The xml:href, xml:rel and
> xml:type _strings_ can be found without understanding namespaces,
> I think.  Maybe I'm trying to skirt around the issue of namespaces,
> but I think using the implicit xml namespace is appropriate because
> web hyperlinking is a top priority use case for xml.

I think that's very subjective - I'd rather add xml:include and xsi:type
myself. But that was why I wrote the "unobtrusive namespace" stuff, so
you could have (in effect) a predeclared list of namespces. It didn't
fly, though.


> > Hmm, I have not seen atom:link in use outside atom, I'd be 
> > interested to learn more about that and see examples.
> 
> https://developers.google.com/kml/documentation/kmlreference#atomlink
> http://www.rssboard.org/rss-profile#namespace-elements-atom-link

The kml one is interesting, are you suggesting Google Earth uses atom in
some way?

The rssboard one is just atom and rss, which is where atom started ;)


> > Sorry for a long reply.
> NP.  Just want to make sure you realize I am not a crank caller.

No, it's OK, and I am interested and listening. Heck, if you're in
Ottawa I'm only 3½ hours' drive away :-)

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Thanks again for the coherent responses, Liam. Especially at 4 am. I hope 
you got a few hours of sleep before reading this!

> No. In this case they should look at the confluence.xsd part. For
> example, if your XML document was hosted at
> http://www.example.org/docs/argyle.xml, then the XML Catalog would be
> consulted for http://www.example.org/docs/confluence.xsd.
> See http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/#schema-loc

Ah, "4.3.2 How schema definitions are located on the Web" ("non-Web 
mechanisms for delivering schemas for ·assessment· exist, but are outside 
the scope of this specification").

Sorry, I fear I should have been clearer, earlier: I am using desktop XML 
editors (such as jEdit and XMLSpy) to work with files that are located 
either on my PC's local (C:) drive or on LAN drives (or that I create from 
scratch in the editor). None of the files involved are located on the Web.

From the "XML Schema Part 0: Primer Second Edition" (
www.w3.org/TR/xmlschema-0/#SchemaInMultDocs):

> As schemas become larger, it is often desirable to divide their content 
among several schema documents [...] Instance documents that conform to 
schema whose definitions span multiple schema documents need only 
reference the 'topmost' document

Also, the Primer refers to "the location of schema documents": that is, it 
refers to schema documents as being persistent objects - with locations - 
as opposed to, say, in-memory objects that might be programmatically 
generated from one or more such persistent objects.

I'm comfortable with the concept that the content of a schema can be 
divided among several schema documents; this describes the Confluence XML 
schema that I've developed.

From your email:

> Second, a Schema Document can be comprised of multiple xsd files.
> Neither I nor the XSD spec uses Schema Document to mean a single xsd 
file.

In the light of your email, I think my problem might be that I've been 
misreading the various W3C documents, and that I've been incorrectly 
thinking: one schema document = one .xsd file = one <schema> element. I 
think you're saying the term "schema document" actually means (please feel 
free to correct me): an .xsd file, *and* any other .xsd files to which it 
refers (via, for example, <import> and <include>). Or are you saying that 
a "schema document" is not just those .xsd files, but a single object that 
is generated (in memory, by an XML processor) from all of those files? (In 
which case, how can the primer refer to the persistent "location" of a 
schema document?)

Finally (cringe, sorry), I'm still not clear on the following issue: in a 
single .xsd file (that does not refer to any other .xsd files, via 
<include>, <import>, or any other means), can I define some elements that 
are associated with one namespace, and other elements that are associated 
with another namespace? I think the answer is "no".

Graham Hannington
Perth, Western Australia

Fundi Software Pty Ltd  2012  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

From my earlier email:

> [I am] hoping to learn more. And I am prepared to publicly expose my 
ignorance to do so

On that note...

I am a user of Atlassian Confluence, a commercial wiki product. I have no 
other affiliation with Atlassian, (Okay, I'm Australian, too.)

Previous (3.x) versions of Confluence stored content in a wiki markup 
format. The current version of Confluence (4) stores content in a 
proprietary XML vocabulary that consists of:

- Elements and attributes that have the same names as a subset of elements 
and attributes in XHTML 1.0 (mostly from XHTML 1.0 Strict, with a few 
additional elements from XHTML 1.0 Transitional). Elements in the 
Confluence XML vocabulary that have the same name as elements in XHTML 1.0 
have a much more limited set of attributes than the XHTML 1.0 elements of 
the same name.

- Proprietary elements and attributes

Some Confluence users have asked Atlassian to provide a schema (DTD, XSD, 
or both) for this XML vocabulary. However, Atlassian has indicated that 
providing a DTD/XSD is not high on its list of current priorities.

So, I have attempted to create the DTD/XSDs myself, based on a combination 
of:

- The XHTML 1.0 Strict DTD (and a few snippets of Transitional)
- The documentation that Atlassian has provided (which falls far short of 
the detail required to develop a DTD/XSD)

- Experimentation with the Confluence rich text editor (to exercise the 
full range of markup that the editor can generate)

- "Forensic analysis" of the XML source of Atlassian's own Confluence 
documentation (Atlassian publishes "exports" of their public 
documentation, containing the XML source of over 4000 pages; so, a 
reasonable-size test bucket) - xmllint was very useful here for automating 
validation, and iteratively refining the constraints of the XSD/DTDs

I hope I'm not breaking any mailing list guidelines here (I don't think 
so; I've just re-read them)...

I welcome feedback (constructive criticism) of these DTD/XSDs.

I'm not offering any money, so feel free to have fun at my expense by 
flaming these files, and my questionable XML skills, to a cinder. Perhaps 
a phoenix will rise from the ashes ;-).

You can download the package (a 30 KB .zip file) from:

http://www.amnet.net.au/~ghannington/confluence/confluence-schema.zip

For details, see the readme.html in the .zip.

I am aware that the tips in the readme on "Using a catalog, rather than 
explicitly referring to the DTD/XSD in each document instance" are, at 
best, incomplete... I'll fix this in the next couple of days, with thanks 
to Liam for his recent advice (on this mailing list).

I hope that the above address will be a temporary home for this package; I 
hope that Atlassian will soon either render the package obsolete by 
providing their own - although I think that's unlikely, given its stated 
priorities - or take ownership of this package.

Graham Hannington
Perth, Western Australia

Fundi Software Pty Ltd  2011  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

I want to make it clear that, in the following schemaLocation attribute 
from my earlier emails:

xsi:schemaLocation="http://www.atlassian.com/schema/confluence/4/ac/ 
confluence.xsd"

there's (supposed to be; is, in my original) a space between the namespace 
URI:

http://www.atlassian.com/schema/confluence/4/ac/

and the XSD URI:

confluence.xsd

(With apologies, I think perhaps I need to look into ensuring that my 
Lotus Notes mail client sends plain text only!)

Graham Hannington
Perth, Western Australia

Fundi Software Pty Ltd  2011  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

This message has been scanned for malware by Websense. http://www.websense.com/

Liam,

> 
> On Thu, 2012-04-19 at 14:37 +0000, Rushforth, Peter wrote:
> > The point is, the media type advertisement that is present in 
> > @xml:type _tells_ the crawler, or any other client, if they will be 
> > able to understand what is at the other end of the @xml:href.
> 
> You can never assume that the result of fetching a resource 
> will be a particular representation format. You might 
> actually get anything back at all. For sure you might get 
> HTML 2 or HTML 4 as part of an HTTP 404 or 401 response, but 
> content negotiation means you might get image/jpeg instead.
> 
> Instead, it tells the client that the document author 
> _expected_ a particular type.
> 
> If we can agree that far maybe we can make progress on 
> understanding each other ;-)


@xml:type is embedded metadata, similar in concept the atom:link@type,
http://tools.ietf.org/html/rfc4287#section-4.2.7.3 and
html:link@type, and is less authoritative than message metadata in http,
as described here: http://www.w3.org/2001/tag/doc/mime-respect#media-type


My understanding of content negotiation is that the client sends an Accept
header with a list of weighted preferences.  If the advertisement
in the @xml:type does not match one of the client's capabilities,
no request to that xml:href URI will ever be made, saving the network bandwidth,
and the server the effort of replying to a request it cannot honour.

> 
> I'm personally interested in typed links, where the types are 
> rhetorical in nature - e.g. "supports", "disagrees", or 
> express other relationships.

This is the relationship of the referenced resource to the current client state,
and is supposed to be stored in @xml:rel, which is similar to atom:link@rel
or html:link@rel.  *I* think you need _both_ @xml:rel and @xml:type to qualify
as a typed link.  

One of the interesting things about @xml:rel and @xml:type is that it constitutes
(part of) "media type design", along the lines of what Fielding talked about in
his famous rant:

"A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types."
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

The domain of design between @xml:rel and @xml:type is a very powerful one.
The art of XML document design is well understood by this crowd,
(ie. the other part of media type design).

I think there are some very important details here that could be improved
by @xml:rel, @xml:type and @xml:href, especially because the addition of
those attributes enable "hypertext-enabled mark-up for existing standard
media types"

In reference to Michael Kay's mention of normalization, I see
the factoring of meaning between the @xml:rel and @xml:type as a kind of 
"web normalization".  Put the stable meaning of resources in their (dynamic) context 
(say, an xml shoe :-)
into one or more tokens in the @xml:rel (eg. "other"), and the 
media type hierarchy into the @xml:type (eg. "application/xml;type=shoe)
Presto, semantic links.

> 
> >   One could write an ISO 19115:2003 crawler, for example, 
> and so long 
> > as the links were annotated with @xml:type, the crawler 
> could target 
> > that media type only, processing the elements in the way it 
> > understands them, doing whatever it needs to do to meet its goals 
> > (this might not be "search", in the google sense, for example).
> 
> Someone else would write a crawler that checked out all the 
> links and fond the 90% that you'd missed, e.g. when you go to 
> www.findmylover.com and you get an HTML page that asks for a 
> country, and then www.findmylover.com/?country=rohan returns 
> your geographical markup language.
> 
> It's dynamic, not static.

Again, the issue about authoritative metadata.

However, without the advertisement found in @xml:type, no such crawler is practical,
because you would have to crawl _everything_ to determine what is/is not
a document you can analyze.  Or else you are assuming that everything is
one or two media types, all of which you can process.  Clearly, that is
not the case with xml, beyond simple xml parsing.


> 
> 
> 
> > > Media type tells you what something is, not how to 
> process it. There 
> > > are lots of things you can do with an SVG image, for example, 
> > > besides simply rendering it.
> > 
> > Media type (@xml:type) tells you what the media type of the 
> advertised 
> > linked representation might be (not: _is_), so you know if 
> you should be able to process it.
> 
> When I wrote Media type I was referring to the label in the 
> returned HTTP header, which is authoritative.

Agreed.  But it is not the only place nor role for the media type metadata,
as described by the TAG reference above.

> 
> > An SVG image might be chosen over a png version so the client could 
> > edit the vectors, for example.  The media type advertisement allows 
> > clients to know if they can send an Accept header with a value 
> > supporting that use.
> 
> The client can *always* send an Accept header saying they 
> prefer PNG to SVG. (content negotiation is of course 
> different from "HTTP OPTIONS")

Yes.  But again, the advertisement in the metadata is a hint to the
client of what to enter into negotiation with.

> 
> 
> [...]
> 
> > For sure, that is what the Accept header is for.  But the 
> html author 
> > uses the link to his own ends, and it sure isn't 
> constrained to html.
> > For xml, where everyone mints his own media type effectively, 
> > @xml:type is essential.
> 
> Maybe this is where I'm not following your argument.
> 
> Are you suggesting people would register individual 
> schemas/vocabularies with IANA themselves, or would use types like
>   application/x-mallard+xml ?

No, I think application/xml is top-level.  There does need to be
some way to continue to specify the document semantics, probably through
media type parameters (that seems to be the extensibility mechanism
that is provided).  If your media type gets important enough that
recognition as application/xml is not important, go ahead and register
application/x-mallard+xml.  IOW application/xml;type=mallard is
probably more appropriate for a domain specific vocabulary.  Clients
who understand type=mallard will quack like a duck, but browsers
and other xml-aware but mallard-unaware applications will just
display xml syntax coloring, or whatever their default behaviour might
be (because they'll ignore ;type=mallard, and request application/xml, 
if they follow the spec).


> 
> > Exactly.  Adding no-namespace-declaration hyperlinks is a 
> big win, IMHO.
> 
> Is the problem the namespace declaration? There was talk 
> about that a year or two ago on xml-dev, about reforming 
> namespaces, but there's too much XML 1.0 inertia to make it easy.

Yes, it is one of the problems.  But I don't think it is the
declaration so much as the fact that users have to declare it and
clients have to verify that it matches.  The xml:href, xml:rel and
xml:type _strings_ can be found without understanding namespaces,
I think.  Maybe I'm trying to skirt around the issue of namespaces,
but I think using the implicit xml namespace is appropriate because
web hyperlinking is a top priority use case for xml.  

> 
> > xml:type isn't putting the media type into the link.  It's 
> advertising 
> > a representation format available from the URI. Very much link 
> > atom:link@type.  Why has atom:link grown beyond atom?  
> Because there 
> > is no equivalent thing in xml.
> 
> Hmm, I have not seen atom:link in use outside atom, I'd be 
> interested to learn more about that and see examples.

https://developers.google.com/kml/documentation/kmlreference#atomlink
http://www.rssboard.org/rss-profile#namespace-elements-atom-link


> 
> Note that we (W3C) did reduce the barrier of XLink a little, 
> you only need one attribute now. And declaring an XLink 
> namespace seems no worse than declaring an atom one to me.

I agree that it is no worse, except for the complexity, not to mention
controversy (apparently, did not know of that before starting this
discussion) around xlink.  Again, having a specific domain standard
add linking to xml is not the right way to go - it needs to be
baked in.  And the namespace is also a slight barrier, per above comments.

> 
> [...]
> 
> > The biggest barrier to use of xml on the web is following 
> web service 
> > paradigms which don't use the web architecture to advantage.
> > And, not having hypertext there when you need it.
> 
> I wonder if we got 20 people in a room together we could get 
> agreement on "the biggest barrier"... :-)
Maybe not.  Not to worry.

> 
> Web services are rapidly moving to JSON.
Stop the bleeding!  Use REST+XML!

> 
> Sorry for a long reply.
NP.  Just want to make sure you realize I am not a crank caller.


Cheers,
Peter 

This message has been scanned for malware by Websense. http://www.websense.com/

On Fri, 2012-04-20 at 15:33 +0800, Graham Hannington wrote:
> [...]

> When an XML document instance contains the 
> following schemaLocation attribute:
> 
> xsi:schemaLocation="http://www.atlassian.com/schema/confluence/4/ac/ 
> confluence.xsd"
> 
> my understanding is that catalog-aware XML applications (such as XMLSpy) 
> look at the first part of that attribute value

No. In this case they should look at the confluence.xsd part. For
example, if your XML document was hosted at
http://www.example.org/docs/argyle.xml, then the XML Catalog would be
consulted for http://www.example.org/docs/confluence.xsd.

See http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/#schema-loc :

The semantics of schemaLocation are that the first item is the namespace
name and the second is the location of a schema document providing
definitions for names in that namespace. But this does not mean such a
schema document is the _only_ schema, or an _authoratative_ schema
desrcibing names in that namespace. There is no such thing as a schema
defining a namespace, because XML doesn't have that concept -- a
namespace is just a URI that you can associate with names in XML
documents if you like.


[...]

> Also this:
> 
> > There is no direct mapping between namespace URIs and Schema documents

> I think a direct mapping between a namespace URI and a 
> schema document is exactly the process that I've just described above, and 
> is exactly what that uri element in a catalog does:
> 
> <uri name="http://www.atlassian.com/schema/confluence/4/ac/" 
> uri="confluence.xsd"/>
> 
> If this uri element does not directly map a namespace URI to a schema 
> document, what does it do?
> 
> Finally:
> 
> > the relationship is that Schema documents may define elements associated 
> with one or more namespace URIs.
> 
> I'm not saying that you're asserting otherwise, but I want to confirm that 
> my current understanding in this area is correct. I think that one schema 
> document (XSD; a single .xsd file) can define elements associated with 
> only one namespace URI (its target namespace).

See the "chameleon" schema pattern for a counter-example.
Second, a Schema Document can be comprised of multiple xsd files.
Neither I nor the XSD spec uses Schema Document to mean a single xsd
file.

> I hope you don't think that I'm challenging you. That's not my intention. 

It wouldn't be a problem if you were, it's OK :-)

On the other hand it's 4am so I might not be all that coherent...

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

On Thu, 2012-04-19 at 14:37 +0000, Rushforth, Peter wrote:
> The point is, the media type advertisement
> that is present in @xml:type _tells_ the crawler, or any other client,
> if they will be able to understand what is at the other end of the
> @xml:href.

You can never assume that the result of fetching a resource will be a
particular representation format. You might actually get anything back
at all. For sure you might get HTML 2 or HTML 4 as part of an HTTP 404
or 401 response, but content negotiation means you might get image/jpeg
instead.

Instead, it tells the client that the document author _expected_ a
particular type.

If we can agree that far maybe we can make progress on understanding
each other ;-)

I'm personally interested in typed links, where the types are rhetorical
in nature - e.g. "supports", "disagrees", or express other
relationships.

>   One could write an ISO 19115:2003 crawler, for example,
> and so long as the links were annotated with @xml:type, the
> crawler could target that media type only, processing the elements in the
> way it understands them, doing whatever it needs to do to meet its
> goals (this might not be "search", in the google sense, for example).

Someone else would write a crawler that checked out all the links and
fond the 90% that you'd missed, e.g. when you go to www.findmylover.com
and you get an HTML page that asks for a country, and then
www.findmylover.com/?country=rohan returns your geographical markup
language.

It's dynamic, not static.



> > Media type tells you what something is, not how to process 
> > it. There are lots of things you can do with an SVG image, 
> > for example, besides simply rendering it.
> 
> Media type (@xml:type) tells you what the media type of the advertised linked
> representation might be (not: _is_), so you know if you should be able to process it.

When I wrote Media type I was referring to the label in the returned
HTTP header, which is authoritative.

> An SVG image might be chosen over a png version so the client could edit 
> the vectors, for example.  The media type advertisement allows clients
> to know if they can send an Accept header with a value supporting that
> use.

The client can *always* send an Accept header saying they prefer PNG to
SVG. (content negotiation is of course different from "HTTP OPTIONS")


[...]

> For sure, that is what the Accept header is for.  But the html author uses
> the link to his own ends, and it sure isn't constrained to html.
> For xml, where everyone mints his own media type effectively, @xml:type
> is essential.

Maybe this is where I'm not following your argument.

Are you suggesting people would register individual schemas/vocabularies
with IANA themselves, or would use types like
  application/x-mallard+xml ?

> Exactly.  Adding no-namespace-declaration hyperlinks is a big win, IMHO.

Is the problem the namespace declaration? There was talk about that a
year or two ago on xml-dev, about reforming namespaces, but there's too
much XML 1.0 inertia to make it easy.

> xml:type isn't putting the media type into the link.  It's advertising
> a representation format available from the URI. Very much link
> atom:link@type.  Why has atom:link grown beyond atom?  Because
> there is no equivalent thing in xml.

Hmm, I have not seen atom:link in use outside atom, I'd be interested to
learn more about that and see examples.

Note that we (W3C) did reduce the barrier of XLink a little, you only
need one attribute now. And declaring an XLink namespace seems no worse
than declaring an atom one to me.

[...]

> The biggest barrier to use of xml on the web is following web service
> paradigms which don't use the web architecture to advantage.
> And, not having hypertext there when you need it.

I wonder if we got 20 people in a room together we could get agreement
on "the biggest barrier"... :-)

Web services are rapidly moving to JSON.

Sorry for a long reply.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

On Fri, 2012-04-20 at 12:29 +0800, Graham Hannington wrote:
> If I want a catalog-aware XML application (such as jEdit with XML plugin, 
> or Altova XMLSpy 2012) to use a catalog to locate XSDs to validate XML 
> document instances, must the XML document instances contain schemaLocation 
> attributes?
No.


> I had hoped that perhaps these applications might look at the xmlns: 
> attribute values (namespace URIs) in a document instance, and use the 
> catalog to map these namespace URIs to the location of the corresponding 
> XSD files, but that does not work for me in practice.

Neither should it.

There is no direct mapping between namespace URIs and Schema documents;
the relationship is that Schema documents may define elements associated
with one or more namespace URIs. It's a many*/many* relationship: an XML
document might not use any namespaces at all and yet still have one or
more XML Schema documents used to validate it. You might use any of
several schema documents (or several at once) depending on your goals.

> 
> So, either:
> - The answer is "yes" (the document instances must contain schemaLocation 
> attributes)
> - The answer is "no", and I'm doing something wrong in my catalog

The answer is that you have to tell your schema processor how to find he
schemas, and that schemaLocation attributes are one way, but not the
only way - the program might have another way to do it - but doing it
based on namespace URIs would not be a good way.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Maybe someone will put out shoes that communicate with Google's new information-enhanced-reality glasses, so that the glasses can warn you when your feet are about to collide with something or step off a curb. 

> -----Original Message-----
> From: Liam R E Quin [mailto:liam@w3.org]
> Sent: Thursday, April 19, 2012 2:44 PM
> To: ian.graham@utoronto.ca
> Cc: xml-dev@lists.xml.org
> Subject: Re:  RE: Footwear
> 
> On Thu, 2012-04-19 at 09:11 -0400, ian.graham@utoronto.ca wrote:
> > Wow. XML Shoes.
> >
> > This puts Liam in a true quandary, doesn't it?
> 
> :-)
> 
> The shoes I was actually thinking of were from Nike I think, and
> communicated with an ipod (which uses XML to do this) to synchronise
> your music with the speed of your running, or something like that.
> 
> Liam
> 
> --
> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
> Pictures from old books: http://fromoldbooks.org/
> 
> 
> _______________________________________________________________________
> 
> 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

Rushforth, Peter scripsit:

> Although they are strictly advisory, according to this note
> 
> http://www.w3.org/2001/tag/doc/mime-respect#metadata-hints

Well, sure.  Just because the client asks for the Lower Slobbovian
translation doesn't obligate the server to provide it.

-- 
"Repeat this until 'update-mounts -v' shows no updates.         John Cowan
You may well have to log in to particular machines, hunt down   cowan@ccil.org
people who still have processes running, and kill them."

Pity - I was hoping for shoes that _looked_ like  markup, with angle  
brackets for heel and toe, and maybe laces that read out attributes.  
That would be very cool ;-)


Quoting Liam R E Quin <liam@w3.org>:

> On Thu, 2012-04-19 at 09:11 -0400, ian.graham@utoronto.ca wrote:
>> Wow. XML Shoes.
>>
>> This puts Liam in a true quandary, doesn't it?
>
> :-)
>
> The shoes I was actually thinking of were from Nike I think, and
> communicated with an ipod (which uses XML to do this) to synchronise
> your music with the speed of your running, or something like that.
>
> Liam
>
> --
> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
> Pictures from old books: http://fromoldbooks.org/
>
>
> _______________________________________________________________________
>
> 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
>
>

Eliot is a faithful and durable cat.  He hoed to the end of that row.  I
bailed when I realized that past the basic ilink/clink concepts, I
didn't have the foggiest notion what the rest of the spec was for. I was
just too dumb.

It's a features-in-contexts challenge.   For the web where many media
types have to be negotiable (blind exchange) and loosely coupled (a link
locator and click detection inside a raster image vs a real time 3D
graphic are the same feature implemented within the constraints of
different media types) proper layering is sine qua non.  Hytime thinking
didn't really factor in the potentials of the environment being capable
of emailing state (async) and that the metadata authority is the
container not the content.  It was originally more concerned with the
linking applications of the media types themselves.

I come back to the IETM and note that attempts to go to databases
driving data packages to presentation systems have fared badly and we
might want to consider an XML native presentation engine where the
application language (what the DTD/schema declares) is handled by style
sheets with built in hypertext controls and a handful of XML-defined
names (say xml:href).

len

-----Original Message-----
From: Liam R E Quin [mailto:liam@w3.org] 
Sent: Thursday, April 19, 2012 1:50 PM
To: Len Bullard
Cc: Rushforth, Peter; xml-dev@lists.xml.org
Subject: RE:  xml:href, xml:rel and xml:type

On Thu, 2012-04-19 at 08:10 -0500, Len Bullard wrote:
> Let's be fair.  Hytime became Elliot's by award and rightfully given
the
> work he put into it, but it was being worked some years before Eliot.

Yes. Eliot was, in a way, to HyTime as Yuri was to SGML.

Layered and loosely-coupled systems win out every time over complex
monolithic ones. Of course, one must not confuse complex systems with
large specifications - the spec might be larger because it is clearer
and more precise, and not only because of new features.

Best,

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

John,

If XLink is to support the web , they should be added for sure.

Although they are strictly advisory, according to this note

http://www.w3.org/2001/tag/doc/mime-respect#metadata-hints

Cheers,
Peter 

> -----Original Message-----
> From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan
> Sent: April 19, 2012 01:58
> To: Liam R E Quin
> Cc: Rushforth, Peter; Len Bullard; xml-dev@lists.xml.org
> Subject: Re:  xml:href, xml:rel and xml:type
> 
> Liam R E Quin scripsit:
> 
> > Indeed, different HTTP clients (browsers) might receive different 
> > formats, depending on the Accept: HTTP headers they send.
> 
> Which is why XInclude has xi:include/@accept and 
> xi:include/@accept-language headers, so that including 
> documents can specify a particular version of included 
> documents to try to fetch.
> 
> These could be added to XLink 1.2 if anyone cared.
> 
> -- 
> Not to perambulate                 John Cowan <cowan@ccil.org>
>     the corridors                  http://www.ccil.org/~cowan
> during the hours of repose
>     in the boots of ascension.       --Sign in Austrian 
> ski-resort hotel
> 

On Thu, 2012-04-19 at 08:10 -0500, Len Bullard wrote:
> Let's be fair.  Hytime became Elliot's by award and rightfully given the
> work he put into it, but it was being worked some years before Eliot.

Yes. Eliot was, in a way, to HyTime as Yuri was to SGML.

Layered and loosely-coupled systems win out every time over complex
monolithic ones. Of course, one must not confuse complex systems with
large specifications - the spec might be larger because it is clearer
and more precise, and not only because of new features.

Best,

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Attach sensors in all the latest fashions and network them to situation
awareness apps noting both personal and neighboring contexts.  The
possibilities are 

.... dreadful.  Or a Saturday Night Live sketch.

len

From: Liam R E Quin [mailto:liam@w3.org] 
Sent: Thursday, April 19, 2012 1:44 PM
To: ian.graham@utoronto.ca
Cc: xml-dev@lists.xml.org
Subject: Re:  RE: Footwear

On Thu, 2012-04-19 at 09:11 -0400, ian.graham@utoronto.ca wrote:
> Wow. XML Shoes.
> 
> This puts Liam in a true quandary, doesn't it?

:-)

The shoes I was actually thinking of were from Nike I think, and
communicated with an ipod (which uses XML to do this) to synchronise
your music with the speed of your running, or something like that.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

On Thu, 2012-04-19 at 09:11 -0400, ian.graham@utoronto.ca wrote:
> Wow. XML Shoes.
> 
> This puts Liam in a true quandary, doesn't it?

:-)

The shoes I was actually thinking of were from Nike I think, and
communicated with an ipod (which uses XML to do this) to synchronise
your music with the speed of your running, or something like that.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Hi Liam, 

> On Tue, 2012-04-17 at 12:05 +0000, Rushforth, Peter wrote:
> [...]
> > Web crawlers, to take one example, can't crawl xml, because 
> there is 
> > no reliable static markup to identify links in all xml.
> 
> There's also no way to mark what's content, which elements 
> break phrases, how to make elements bold or italic, which 
> elements are titles, that Web crawlers need to generate 
> result snippets.

This is because its XML, and html crawlers don't speak an infinite
number of media types/vocabularies.  The point is, the media type advertisement
that is present in @xml:type _tells_ the crawler, or any other client,
if they will be able to understand what is at the other end of the
@xml:href.  One could write an ISO 19115:2003 crawler, for example,
and so long as the links were annotated with @xml:type, the
crawler could target that media type only, processing the elements in the
way it understands them, doing whatever it needs to do to meet its
goals (this might not be "search", in the google sense, for example).


> >   The existence of xml:href solves that problem.
> > Unless they are Kreskin crawlers they won't know what to do 
> with the xml when they find it.
> > That is what @xml:type is there for.  While application/xml 
> does not 
> > tell you too much, there are sub sub media types, media type 
> > parameters etc to tell you how to process the 
> representation once you retrieve it.  Also, it does not have 
> to be xml :-).
> 
> Media type tells you what something is, not how to process 
> it. There are lots of things you can do with an SVG image, 
> for example, besides simply rendering it.

Media type (@xml:type) tells you what the media type of the advertised linked
representation might be (not: _is_), so you know if you should be able to process it.

An SVG image might be chosen over a png version so the client could edit 
the vectors, for example.  The media type advertisement allows clients
to know if they can send an Accept header with a value supporting that
use.  It's not authoritative, of course, because its metadata in a
representation, but it allows for potential efficiencies  eg not having
to send an OPTIONS to determine media type availability.

> Putting media types in static content is generally not a good 
> architecture. The remote Web server will send a media type as 
> an HTTP header and that is what should be used - it is 
> normative, authoritative. 
> This is why, in HTML, it's <a href="foo"> and not <a href="fo"
> type="text/html">
> 
> Indeed, different HTTP clients (browsers) might receive 
> different formats, depending on the Accept: HTTP headers they send.

For sure, that is what the Accept header is for.  But the html author uses
the link to his own ends, and it sure isn't constrained to html.
For xml, where everyone mints his own media type effectively, @xml:type
is essential.

> 
> > 
> > Why is xml:lang needed for xml itself?  or xml:base for that matter?
> > Why is linking less important?
> 
> Where you start and stop is fairly arbitrary. We didn't do 
> xml:id in the first spec either.

Exactly.  Adding no-namespace-declaration hyperlinks is a big win, IMHO.
Take xml:base.  That attribute is in the same spirit as xml:href, I think,
except it describes *this* document, not *that* document.

> 
> Peter, the people you need to persuade here mostly fall into 
> two broad camps - (1) people happy with XML and namespaces 
> and who generally see little or no problem with XLink. XLink 
> already has the ability to describe the "state of the cilent" 
> as you call it, to specify link relationships (like the rel 
> attribute on "a" and "link" in HTML), and does not have the 
> Web-architecture-breakage of putting media types into links 
> ;-)... and 

xml:type isn't putting the media type into the link.  It's advertising
a representation format available from the URI. Very much link
atom:link@type.  Why has atom:link grown beyond atom?  Because
there is no equivalent thing in xml.  Nothing against xlink; use
it if it fits your needs.  The point is all of xml needs links
to other documents, and the barrier of xlink is too high.

(2) people who have no interest in using XML on 
> the Web today, and for whom the difference between xlink:href 
> and xml:href is like saying, buy a Jeep because the rear axle 
> leaf spring bushings are polyurethane whereas in a Toyota 
> they're aluminium.

> The biggest barrier to XML on the Web today is that when Aunt 
> Tillie tries it, and leaves quotes of her attribute values, 
> she gets a really confusing error message.
> 
> The next biggest is lack of architectural forms for search 
> crawlers and ad servers to use.
> 
> Without ads, and with strict syntax, we're not about to take 
> over the world.

The biggest barrier to use of xml on the web is following web service
paradigms which don't use the web architecture to advantage.
And, not having hypertext there when you need it.

> We are limited in the ways we can change XML itself, although 
> we can change the layers above more easily.
It's the easy part that prevents interoperability on a grand 
scale.  Of course, XML is all about making certain things easy.
The other stuff, the really really really important stuff, should
come built in and fixed.

Cheers,
Peter

http://www.chictopia.com/xml-shoes-qq/xml/fashion/clothes-shoes

----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org


> -----Original Message-----
> From: Norm Birkett [mailto:Norm.Birkett@reval.com]
> Sent: Thursday, April 19, 2012 8:42 AM
> To: xml-dev@lists.xml.org
> Subject:  Footwear
> 
> > -----Original Message-----
> > From: Liam R E Quin [mailto:liam@w3.org]
> ...
> > XML is used ... in shoes.... OK, not in _all_ shoes, but there were
> > some. Honest ;)
> ...
> 
> Some sort of advanced, dynamic running shoe, maybe? Or ultra-high-heel
> platforms with self-balancing features to make them safer for starlets? The
> footie component of recent spacesuits? Hazmat boots with radiation-level
> logging? Automatic self-camoflaging army boots?
> 
> Or was it just Maxwell Smart's shoe phone? (But I always thought that was an
> analog device.)
> 
> Norm
> 
> 
> ________________________________________________________________
> _______
> 
> 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
> 

> -----Original Message-----
> From: Liam R E Quin [mailto:liam@w3.org]
...
> XML is used ... in shoes.... OK, not in _all_ shoes, but there were
> some. Honest ;)
...

Some sort of advanced, dynamic running shoe, maybe? Or ultra-high-heel platforms with self-balancing features to make them safer for starlets? The footie component of recent spacesuits? Hazmat boots with radiation-level logging? Automatic self-camoflaging army boots?

Or was it just Maxwell Smart's shoe phone? (But I always thought that was an analog device.)

Norm

From cited document:

"For Web architecture, a design choice has been made that metadata
received in an encapsulating container MUST be considered authoritative
and used in preference to metadata found by inspection of the data,
declared by embedded metadata, or provided by external reference.
Although this design choice is generally applicable to any container
format, including archival formats that encapsulate other data, the most
significant interpretation for Web architecture is that representation
metadata found within the header fields of a received message shall be
considered authoritative for the representation encapsulated within that
message."

And that is a system constraint.  IOW, on the web/off the web is
systemically meaningful and this is why:  governing authority at the
point of making meaningful choices, deciding probability in advance.

Expectations are powerful.  Explain to your boss (as I was a few minutes
ago) why ID/IDREF relationships are meaningful as XML typed
relationships in the XML entity but are NOT hyperlinks and why.  Anyone
writing a history should devote a chapter or three to this precise issue
because almost everything that follows technically after 1996 at the
publishing of the MIME/Multipart specification diverges here.  The
network definition seizes authority over the document itself.  It is the
system handler taking charge over the content being handled.   

As long as all that is wanted is a control handler, this is fine.  As
soon as the data (say href-marked) is applied as a different kind of
metadata (eg, to denote an abstract relationship), it goes to complexity
hell with question "is this de-referenceable?" being the signpost up
ahead and you are in the twilight zone.

A description of the contents of the Cheerios box may be litigable but
it isn't affective once the cereal is in the bowl of milk.  Thus
self-descriptive data formats.

len


-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] 
Sent: Thursday, April 19, 2012 9:51 AM
To: John Cowan; Liam R E Quin
Cc: Len Bullard; xml-dev@lists.xml.org
Subject: RE:  xml:href, xml:rel and xml:type

John,

If XLink is to support the web , they should be added for sure.

Although they are strictly advisory, according to this note

http://www.w3.org/2001/tag/doc/mime-respect#metadata-hints

Cheers,
Peter 

> -----Original Message-----
> From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan
> Sent: April 19, 2012 01:58
> To: Liam R E Quin
> Cc: Rushforth, Peter; Len Bullard; xml-dev@lists.xml.org
> Subject: Re:  xml:href, xml:rel and xml:type
> 
> Liam R E Quin scripsit:
> 
> > Indeed, different HTTP clients (browsers) might receive different 
> > formats, depending on the Accept: HTTP headers they send.
> 
> Which is why XInclude has xi:include/@accept and 
> xi:include/@accept-language headers, so that including 
> documents can specify a particular version of included 
> documents to try to fetch.
> 
> These could be added to XLink 1.2 if anyone cared.
> 
> -- 
> Not to perambulate                 John Cowan <cowan@ccil.org>
>     the corridors                  http://www.ccil.org/~cowan
> during the hours of repose
>     in the boots of ascension.       --Sign in Austrian 
> ski-resort hotel
> 
_______________________________________________________________________

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

Wow. XML Shoes.

This puts Liam in a true quandary, doesn't it?

Quoting David Lee <dlee@calldei.com>:

> http://www.chictopia.com/xml-shoes-qq/xml/fashion/clothes-shoes
>
> ----------------------------------------
> David A. Lee
> dlee@calldei.com
> http://www.xmlsh.org
>
>
>> -----Original Message-----
>> From: Norm Birkett [mailto:Norm.Birkett@reval.com]
>> Sent: Thursday, April 19, 2012 8:42 AM
>> To: xml-dev@lists.xml.org
>> Subject:  Footwear
>>
>> > -----Original Message-----
>> > From: Liam R E Quin [mailto:liam@w3.org]
>> ...
>> > XML is used ... in shoes.... OK, not in _all_ shoes, but there were
>> > some. Honest ;)
>> ...
>>
>> Some sort of advanced, dynamic running shoe, maybe? Or ultra-high-heel
>> platforms with self-balancing features to make them safer for starlets? The
>> footie component of recent spacesuits? Hazmat boots with radiation-level
>> logging? Automatic self-camoflaging army boots?
>>
>> Or was it just Maxwell Smart's shoe phone? (But I always thought that was an
>> analog device.)
>>
>> Norm
>>
>>
>> ________________________________________________________________
>> _______
>>
>> 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
>>
>
>
>
> _______________________________________________________________________
>
> 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
>
>

Let's be fair.  Hytime became Elliot's by award and rightfully given the
work he put into it, but it was being worked some years before Eliot.
In fact, if you have the technical history of Hytime by example, you
have most of everything ever tried in hypertext linking.  The original
drafts are almost identical to what would become web HTML long before it
stopped to REST (again, be fair: REST is a retrofit). Arch forms come at
the end of a long line of good tries.  Timing and luck and implementors:
at the end of the day, it comes down to implementors.

An XML hypertext engine that plays well with REST and ignores undeclared
gencodes is a viable approach if "anyone cares".   It would be a
continual frenetic activity of choosing what to implement and what is
too application-specific to care.    IADS/IDEAS was just that: a fixed
set of tags that then became tag types and eventually a morass of
processing instructions and the rest of straight-up XML before there was
an XML with a style sheet per document type.  No RDBs needed or wanted.

Why do it?  Why do hypertext PDF?

If you want to look at the ultimate complex approach, look at S1000D
where a configuration management approach dominates the design over a
Common Source Data Base.  Lots of money spent but suspended in gaffa
otherwise.  Why?  So far it doesn't solve problems people care about for
the cost of the solution.  John Junod (hey, john) may drop by to pound
me for saying that.

len

-----Original Message-----
From: Liam R E Quin [mailto:liam@w3.org] 
Sent: Wednesday, April 18, 2012 11:20 PM
To: Rushforth, Peter
Cc: Len Bullard; xml-dev@lists.xml.org
Subject: RE:  xml:href, xml:rel and xml:type

On Tue, 2012-04-17 at 12:05 +0000, Rushforth, Peter wrote:
[...]
> Web crawlers, to take one example, can't crawl xml, because there is
no reliable static
> markup to identify links in all xml.

There's also no way to mark what's content, which elements break
phrases, how to make elements bold or italic, which elements are titles,
that Web crawlers need to generate result snippets.

Arch Forms were the HyTime/Eliot-Compatible Approach (HTECA).


>   The existence of xml:href solves that problem.
> Unless they are Kreskin crawlers they won't know what to do with the
xml when they find it.
> That is what @xml:type is there for.  While application/xml does not
tell you too
> much, there are sub sub media types, media type parameters etc to tell
you how
> to process the representation once you retrieve it.  Also, it does not
have to be xml :-).

Media type tells you what something is, not how to process it. There are
lots of things you can do with an SVG image, for example, besides simply
rendering it.

> 
> Finally, applications which use xml on the web need a way to decide /
let the
> client decide what state is the next state for the client.  That is
what @xml:rel 
> is for.
> 
> How is this different from xlink?  For one thing, it is static shared
markup that
> can be reliably used by the entire community.  For another, xlink:type
and xml:type are
> different. xlink:type describes the processing of the link, while
xml:type advertises
> the media type that may be negotiable from the server (no guarantees,
after all its
> the server's resource).

Putting media types in static content is generally not a good
architecture. The remote Web server will send a media type as an HTTP
header and that is what should be used - it is normative,
authoritative. 
This is why, in HTML, it's <a href="foo"> and not <a href="fo"
type="text/html">

Indeed, different HTTP clients (browsers) might receive different
formats, depending on the Accept: HTTP headers they send.

> 
> Why is xml:lang needed for xml itself?  or xml:base for that matter?
> Why is linking less important?

Where you start and stop is fairly arbitrary. We didn't do xml:id in the
first spec either.

Peter, the people you need to persuade here mostly fall into two broad
camps - (1) people happy with XML and namespaces and who generally see
little or no problem with XLink. XLink already has the ability to
describe the "state of the cilent" as you call it, to specify link
relationships (like the rel attribute on "a" and "link" in HTML), and
does not have the Web-architecture-breakage of putting media types into
links ;-)... and (2) people who have no interest in using XML on the Web
today, and for whom the difference between xlink:href and xml:href is
like saying, buy a Jeep because the rear axle leaf spring bushings are
polyurethane whereas in a Toyota they're aluminium.

The biggest barrier to XML on the Web today is that when Aunt Tillie
tries it, and leaves quotes of her attribute values, she gets a really
confusing error message.

The next biggest is lack of architectural forms for search crawlers and
ad servers to use.

Without ads, and with strict syntax, we're not about to take over the
world.

That's actually fine, too. XML is used in televisions, in DVD players,
in music players, in 'plane navigation systems, in shoes, in car
engines, all over the world. OK, not in _all_ shoes, but there were
some. Honest ;)

We are limited in the ways we can change XML itself, although we can
change the layers above more easily.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/


_______________________________________________________________________

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

This is a one-time post to announce the Serene 0.6.1 release.

The purpose of the Serene project is to create an open source
validation engine implementing the JAXP 1.3 Validation Framework API
for RELAX NG, that concentrates on good messages and a clear handling
of ambiguity and conflicts.

For this release, Serene has been extensively reviewed and refactored
in order to improve performance. Some bugs were fixed, messages were
slightly tweaked, one feature was added.

For more information, please come to
 http://code.google.com/p/serene/

Thank you,
Radu Cernuta

Liam R E Quin scripsit:

> Indeed, different HTTP clients (browsers) might receive different
> formats, depending on the Accept: HTTP headers they send.

Which is why XInclude has xi:include/@accept and xi:include/@accept-language
headers, so that including documents can specify a particular version of
included documents to try to fetch.

These could be added to XLink 1.2 if anyone cared.

-- 
Not to perambulate                 John Cowan <cowan@ccil.org>
    the corridors                  http://www.ccil.org/~cowan
during the hours of repose
    in the boots of ascension.       --Sign in Austrian ski-resort hotel

On Tue, 2012-04-17 at 12:05 +0000, Rushforth, Peter wrote:
[...]
> Web crawlers, to take one example, can't crawl xml, because there is no reliable static
> markup to identify links in all xml.

There's also no way to mark what's content, which elements break
phrases, how to make elements bold or italic, which elements are titles,
that Web crawlers need to generate result snippets.

Arch Forms were the HyTime/Eliot-Compatible Approach (HTECA).


>   The existence of xml:href solves that problem.
> Unless they are Kreskin crawlers they won't know what to do with the xml when they find it.
> That is what @xml:type is there for.  While application/xml does not tell you too
> much, there are sub sub media types, media type parameters etc to tell you how
> to process the representation once you retrieve it.  Also, it does not have to be xml :-).

Media type tells you what something is, not how to process it. There are
lots of things you can do with an SVG image, for example, besides simply
rendering it.

> 
> Finally, applications which use xml on the web need a way to decide / let the
> client decide what state is the next state for the client.  That is what @xml:rel 
> is for.
> 
> How is this different from xlink?  For one thing, it is static shared markup that
> can be reliably used by the entire community.  For another, xlink:type and xml:type are
> different. xlink:type describes the processing of the link, while xml:type advertises
> the media type that may be negotiable from the server (no guarantees, after all its
> the server's resource).

Putting media types in static content is generally not a good
architecture. The remote Web server will send a media type as an HTTP
header and that is what should be used - it is normative,
authoritative. 
This is why, in HTML, it's <a href="foo"> and not <a href="fo"
type="text/html">

Indeed, different HTTP clients (browsers) might receive different
formats, depending on the Accept: HTTP headers they send.

> 
> Why is xml:lang needed for xml itself?  or xml:base for that matter?
> Why is linking less important?

Where you start and stop is fairly arbitrary. We didn't do xml:id in the
first spec either.

Peter, the people you need to persuade here mostly fall into two broad
camps - (1) people happy with XML and namespaces and who generally see
little or no problem with XLink. XLink already has the ability to
describe the "state of the cilent" as you call it, to specify link
relationships (like the rel attribute on "a" and "link" in HTML), and
does not have the Web-architecture-breakage of putting media types into
links ;-)... and (2) people who have no interest in using XML on the Web
today, and for whom the difference between xlink:href and xml:href is
like saying, buy a Jeep because the rear axle leaf spring bushings are
polyurethane whereas in a Toyota they're aluminium.

The biggest barrier to XML on the Web today is that when Aunt Tillie
tries it, and leaves quotes of her attribute values, she gets a really
confusing error message.

The next biggest is lack of architectural forms for search crawlers and
ad servers to use.

Without ads, and with strict syntax, we're not about to take over the
world.

That's actually fine, too. XML is used in televisions, in DVD players,
in music players, in 'plane navigation systems, in shoes, in car
engines, all over the world. OK, not in _all_ shoes, but there were
some. Honest ;)

We are limited in the ways we can change XML itself, although we can
change the layers above more easily.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Len,

Pleasantly surprised!   
> You might be surprised to know I support the idea, Peter.  In 
> days of old, SGML hypertext systems did not require 
> downtranslation to a gencode
> such as HTML and it's family of variants.   We could create a DTD,
> create a stylesheet corresponding to it and using the 
> reserved attributes of the specific hypertext engine (what 
> HTML5 really is), display, navigate and retrieve as well as 
> do various limited GUI
> magicks.   My point of view is that types such as xml:href are
> essentially that:  local engine controls for some n of local.
> 


Thanks for that.

Cheers,
Peter

No problem.  I'm in the unique slot, as Ken Holmann said, to eat my own
dog food.   I probably am the one who inserted those references to
Hytime some decades ago before I left for another life; so evolution has
bypassed this backwater of markup.   It is definitely ripe for upgrades
and it is a major user and distributor of XML Off The Web.

IMO, it shouldn't matter any longer if the XML user is off or on the
web.  Enough.  Battle over.  Web wins.  Tech is just tech and if we can
get a productivity/quality burst in these high cost/low pay days, let's
consider it.  Why NOT have an XML hypertext engine with full
capabilities?  There is NO reason why it has to be a gencoded system.   

<emphasis>HTML5 is lazy thinking.</emphasis>

Imagine a 1400 page manual that has a few thousand xrefs being managed
by hand as the different manual parts are being assembled for final
rendering.  ID/IDREF checking is helpful but not nearly enough.  An
author and a user of the manual MUST be able to dereference those items.
This is quite literally a matter of life and death.   Consider a
procedure referencing, for example, an expendable item such as a sealant
compound with an xref pointing to the item listing of that compound in a
table of expendable items and there are five different types of sealants
ALL called sealant compound.   It is your job to put the references in
as an XML tagger and there are no SMEs to tell you which one is used in
which procedure.

Now imagine you are flying in a rotary aircraft at 175 knots that has
just come out of the shop for repairs that required sealant compounds.

Usually the mechs are smart enough to know but...

len

-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] 
Sent: Tuesday, April 17, 2012 11:59 AM
To: Len Bullard
Cc: xml-dev@lists.xml.org
Subject: RE:  xml:href, xml:rel and xml:type

Len,

Pleasantly surprised!   
> You might be surprised to know I support the idea, Peter.  In 
> days of old, SGML hypertext systems did not require 
> downtranslation to a gencode
> such as HTML and it's family of variants.   We could create a DTD,
> create a stylesheet corresponding to it and using the 
> reserved attributes of the specific hypertext engine (what 
> HTML5 really is), display, navigate and retrieve as well as 
> do various limited GUI
> magicks.   My point of view is that types such as xml:href are
> essentially that:  local engine controls for some n of local.
> 


Thanks for that.

Cheers,
Peter

Hi Len,

The scope for these attributes is web linking.  I can see that there should
be a strict constraint on what gets put into the xml namespace.  xml codifies
a very few but very important things. xml:lang, xml:base and a couple of others.

My point of view on this is that html is "big" because it is static and shared.  xml needs
a bit of this static shared stuff to make it more amenable to certain uses.  Goal #1 of XML
was to be simple to use on the web.    To be simple to use,
it needs to have some static, reliably present markup which can be acted on.

Web crawlers, to take one example, can't crawl xml, because there is no reliable static
markup to identify links in all xml.  The existence of xml:href solves that problem.
Unless they are Kreskin crawlers they won't know what to do with the xml when they find it.
That is what @xml:type is there for.  While application/xml does not tell you too
much, there are sub sub media types, media type parameters etc to tell you how
to process the representation once you retrieve it.  Also, it does not have to be xml :-).

Finally, applications which use xml on the web need a way to decide / let the
client decide what state is the next state for the client.  That is what @xml:rel 
is for.

How is this different from xlink?  For one thing, it is static shared markup that
can be reliably used by the entire community.  For another, xlink:type and xml:type are
different. xlink:type describes the processing of the link, while xml:type advertises
the media type that may be negotiable from the server (no guarantees, after all its
the server's resource). 

Why is xml:lang needed for xml itself?  or xml:base for that matter?  Why is linking less important?

Cheers,
Peter

> -----Original Message-----
> From: Len Bullard [mailto:cbullard@hiwaay.net] 
> Sent: April 16, 2012 21:03
> To: Rushforth, Peter; 'Simon St.Laurent'
> Cc: liam@w3.org; xml-dev@l...
> Subject: RE:  xml:href, xml:rel and xml:type
> 
> Not to worry, Peter.  We've practiced. :)
> 
> Essentially, xml:href adds application semantics to the XML 
> specification.
> XML abhors application semantics in its specification.  Adding those
> violates the simplicity constraint.   Application 
> specifications are free to
> do that.  IOW, you are asking the wrong list.  Or maybe not, 
> but the point is, XML doesn't specify XML applications past 
> what is needed for XML itself.
> 
> 
> Functional specifications for inter XML linking are a snap.  
> Functional linking to other media types is built into the web.
> 
> What is the scope for xml:href linking and how does that 
> differ from what is currently possible with previously 
> specified technologies?
> 
> One compelling argument for functionally-spec'd XML is 
> authoring common document type collections, eg, TOCs, typed 
> indices, figure/table
> collections, etc.   Tbese are human cultural notation types.  
> Building those
> into a system for use by humans is never wrong, IMHO.
> 
> len
> 
> 
> 
> -----Original Message-----
> From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca]
> Sent: Monday, April 16, 2012 6:55 PM
> To: Len Bullard; Simon St.Laurent
> Cc: liam@w3.org; xml-dev@l...
> Subject: RE:  xml:href, xml:rel and xml:type
> 
> Not to  preach, but I have always felt that respect for what 
> has been achieved is a good place to start any conversation.
> 
> I am merely asking why some simple steps can't be taken to 
> move the yardsticks a bit.  Not any steps:
> the steps I am proposing.
> 
> Cheers,
> Peter
> ________________________________________
> From: Len Bullard [Len.Bullard@ses-i.com]
> Sent: April 16, 2012 4:36 PM
> To: Simon St.Laurent; Rushforth, Peter
> Cc: liam@w3.org; xml-dev@l...
> Subject: RE:  xml:href, xml:rel and xml:type
> 
> And so it begins.
> 
> The early HTML people disdained SGML as overbuilt and too 
> hard to understand because they had yet to understand how and 
> why it worked for the applications to which it had been 
> applied.  The SGML people returned the disdain but helped them anyway.
> 
> Some decades on, as predicted, attempts to reinvent the early 
> work on hypertext by the SGML community that evolved into the 
> XML community continue.  At this point, everyone shares A 
> working system so those
> attempts have yet to produce a compelling case.   It is somewhat as if
> once shown that a Ford A-model could double as a truck, no 
> one needed anything better.  Cab heat would be nice but who 
> wants to put the fur traders out of business?
> 
> Why no xml:href?   How many systems does it take to change a 
> light bulb?
> No one cares while the bulb is lit.
> 
> Why bolt a function-type system onto a syntax standard?  
> (Linking is a process; not data).
> 
> len
> 
> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Sent: Monday, April 16, 2012 3:15 PM
> To: Rushforth, Peter
> Cc: liam@w3.org; xml-dev@l...
> Subject: Re:  xml:href, xml:rel and xml:type
> 
> 
> The early XML folks may have found HTML to be not what they 
> wanted, and seriously lacking in many respects, and the 
> people driving the HTML conversation today return the disdain
> 
> 
> What a misfire!
> 
> 
> ______________________________________________________________
> _________
> 
> 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
> 
> 
> 

You might be surprised to know I support the idea, Peter.  In days of
old, SGML hypertext systems did not require downtranslation to a gencode
such as HTML and it's family of variants.   We could create a DTD,
create a stylesheet corresponding to it and using the reserved
attributes of the specific hypertext engine (what HTML5 really is),
display, navigate and retrieve as well as do various limited GUI
magicks.   My point of view is that types such as xml:href are
essentially that:  local engine controls for some n of local.

Betty Harvey may want to contribute here.  I don't think there are many
of us left who are familiar with what follows.

Why this idea is interesting even today:  I'd guess a majority of XML
users are not document specialists; they are bits on the wire
messengers.  OTOH,  I am a daily user/applier of one of the oldest still
viable type defs for marking up a document class: 40051/2361 with
clearly traceable roots to SGML. What follows is to show a case where a
consistent application of your proposal could improve effort although it
is not a web language application.  It creates a file resource for PDF
displays and IETM down translations.  There is also an extref for
references to external documents.

The linking information is spread out across the elements, but there is
one major cross-reference, the XREF.  For discussion's sake, here is the
element type declaration with its comment.   Note that in 2012, it
stills mentions Hytime links, fosi restrictions, etc.  I provide this as
an example of where progress along certain lines of hypertext
development froze in place as we wandered off to do thingsWeb.   The
restriction to a single entity kept it from being forced to move to the
web technology; yet, in practice, the endpoints of most of the
proto-links (id/idrefs) are produced in separate entities.  Because SGML
pushed a link through an entity declaration for indirection, all of the
information is there except the hypertext type information.  IOW, it has
no concept of a URL.  

<!ELEMENT xref EMPTY>
<!ATTLIST xref  taskid    IDREF  #IMPLIED
                  wpid      IDREF  #IMPLIED
                  stepstart IDREF  #IMPLIED
                  stepend   IDREF  #IMPLIED
                  figid     IDREF  #IMPLIED
                  itemno    CDATA  #IMPLIED
                  itemid    IDREF  #IMPLIED
                  callout   CDATA  #IMPLIED
                  tableid   IDREF  #IMPLIED
                  tslocid   IDREF  #IMPLIED
                  pagelocid IDREF  #IMPLIED
                  pretext   CDATA  #IMPLIED
                  posttext  CDATA  #IMPLIED
                  termdefid IDREF  #IMPLIED
                  security  (uc | fouo | c | s | ts )  #IMPLIED
			restrict NMTOKENS  #IMPLIED
			release  NMTOKENS  #IMPLIED
			codeword NMTOKENS  #IMPLIED
			scilevel  (0 | 1 )  '0'
			diglyph  NMTOKENS  #IMPLIED >

<!-- 
This element and its attributes are for classic cross-references in
paper manuals or for simple electronic links. References may be to
entire work packages, to maintenance task keywords, to titled
procedures, to whole steps, to titled figures, to titled tables, and to
page numbers.
 
Consistent use of "xref" makes updating and revisions more manageable.
Items to be referenced must have their IDREF "typed" by using the
appropriate attribute. 

"WPID" is the mother attribute; if a reference occurs in a work package
other than the current one, a "wpid" must be supplied.  

Text surrounding the reference, when in paper form, is inserted through
attributes "pretext" and "posttext," e.g., "see" and parentheses. The
order of expression shall be: 

pretext?, wpid?, ((taskid, stepstart?, stepend?) | figid | tableid |
logicnodeid | tslocid | pagelocid)+, postext?. 

References to steps or to logic nodes and other troubleshooting
locations must also include a reference to either a work package (if
different than current location) or a task (if different than the
current location within the same WP). If a single step is being
referenced, use "stepstart" only ("stepend" will be assumed to be
identical); if a range of steps is being referenced, supply both
"stepstart" and "stepend" values. Only first-level steps can be
referenced, since only they carry a unique identifier. 
The specific attributes for data types will enable transformations from
Hytime clinks to ilinks in the future. 
-->

This is the extref.  Note the use of CDATA.

!-- following attributes will allow transformations to ilinks in
future; FOSI currently supports "wpid" only -->

<!ELEMENT extref EMPTY>
<!ATTLIST extref  docno    CDATA  #IMPLIED
                    revno    CDATA  #IMPLIED
                    pretext  CDATA  #IMPLIED
                    posttext CDATA  #IMPLIED
                    wpid     CDATA  #IMPLIED
                    taskid   CDATA  #IMPLIED
                    figid    CDATA  #IMPLIED
                    tableid  CDATA  #IMPLIED
                    partid   CDATA  #IMPLIED....

<!-- 
This element and its attributes are for references to other documents
and locations within those documents. Note that the writer may have to
supply a value for revision level of the document being referenced. Text
surrounding the reference, when in paper form, is inserted through
attributes "pretext" and "posttext," e.g., "see" and parentheses; the
type of content, 
such as TS object, supporting information, table or other object, can be
inserted through "pretext." 
-->

len

-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] 
Sent: Tuesday, April 17, 2012 7:05 AM
To: Len Bullard
Cc: xml-dev@lists.xml.org
Subject: RE:  xml:href, xml:rel and xml:type

Hi Len,

The scope for these attributes is web linking.  I can see that there
should
be a strict constraint on what gets put into the xml namespace.  xml
codifies
a very few but very important things. xml:lang, xml:base and a couple of
others.

My point of view on this is that html is "big" because it is static and
shared.  xml needs
a bit of this static shared stuff to make it more amenable to certain
uses.  Goal #1 of XML
was to be simple to use on the web.    To be simple to use,
it needs to have some static, reliably present markup which can be acted
on.

Web crawlers, to take one example, can't crawl xml, because there is no
reliable static
markup to identify links in all xml.  The existence of xml:href solves
that problem.
Unless they are Kreskin crawlers they won't know what to do with the xml
when they find it.
That is what @xml:type is there for.  While application/xml does not
tell you too
much, there are sub sub media types, media type parameters etc to tell
you how
to process the representation once you retrieve it.  Also, it does not
have to be xml :-).

Finally, applications which use xml on the web need a way to decide /
let the
client decide what state is the next state for the client.  That is what
@xml:rel 
is for.

How is this different from xlink?  For one thing, it is static shared
markup that
can be reliably used by the entire community.  For another, xlink:type
and xml:type are
different. xlink:type describes the processing of the link, while
xml:type advertises
the media type that may be negotiable from the server (no guarantees,
after all its
the server's resource). 

Why is xml:lang needed for xml itself?  or xml:base for that matter?
Why is linking less important?

Cheers,
Peter

> -----Original Message-----
> From: Len Bullard [mailto:cbullard@hiwaay.net] 
> Sent: April 16, 2012 21:03
> To: Rushforth, Peter; 'Simon St.Laurent'
> Cc: liam@w3.org; xml-dev@l...
> Subject: RE:  xml:href, xml:rel and xml:type
> 
> Not to worry, Peter.  We've practiced. :)
> 
> Essentially, xml:href adds application semantics to the XML 
> specification.
> XML abhors application semantics in its specification.  Adding those
> violates the simplicity constraint.   Application 
> specifications are free to
> do that.  IOW, you are asking the wrong list.  Or maybe not, 
> but the point is, XML doesn't specify XML applications past 
> what is needed for XML itself.
> 
> 
> Functional specifications for inter XML linking are a snap.  
> Functional linking to other media types is built into the web.
> 
> What is the scope for xml:href linking and how does that 
> differ from what is currently possible with previously 
> specified technologies?
> 
> One compelling argument for functionally-spec'd XML is 
> authoring common document type collections, eg, TOCs, typed 
> indices, figure/table
> collections, etc.   Tbese are human cultural notation types.  
> Building those
> into a system for use by humans is never wrong, IMHO.
> 
> len
> 
> 
> 
> -----Original Message-----
> From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca]
> Sent: Monday, April 16, 2012 6:55 PM
> To: Len Bullard; Simon St.Laurent
> Cc: liam@w3.org; xml-dev@l...
> Subject: RE:  xml:href, xml:rel and xml:type
> 
> Not to  preach, but I have always felt that respect for what 
> has been achieved is a good place to start any conversation.
> 
> I am merely asking why some simple steps can't be taken to 
> move the yardsticks a bit.  Not any steps:
> the steps I am proposing.
> 
> Cheers,
> Peter
> ________________________________________
> From: Len Bullard [Len.Bullard@ses-i.com]
> Sent: April 16, 2012 4:36 PM
> To: Simon St.Laurent; Rushforth, Peter
> Cc: liam@w3.org; xml-dev@l...
> Subject: RE:  xml:href, xml:rel and xml:type
> 
> And so it begins.
> 
> The early HTML people disdained SGML as overbuilt and too 
> hard to understand because they had yet to understand how and 
> why it worked for the applications to which it had been 
> applied.  The SGML people returned the disdain but helped them anyway.
> 
> Some decades on, as predicted, attempts to reinvent the early 
> work on hypertext by the SGML community that evolved into the 
> XML community continue.  At this point, everyone shares A 
> working system so those
> attempts have yet to produce a compelling case.   It is somewhat as if
> once shown that a Ford A-model could double as a truck, no 
> one needed anything better.  Cab heat would be nice but who 
> wants to put the fur traders out of business?
> 
> Why no xml:href?   How many systems does it take to change a 
> light bulb?
> No one cares while the bulb is lit.
> 
> Why bolt a function-type system onto a syntax standard?  
> (Linking is a process; not data).
> 
> len
> 
> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Sent: Monday, April 16, 2012 3:15 PM
> To: Rushforth, Peter
> Cc: liam@w3.org; xml-dev@l...
> Subject: Re:  xml:href, xml:rel and xml:type
> 
> 
> The early XML folks may have found HTML to be not what they 
> wanted, and seriously lacking in many respects, and the 
> people driving the HTML conversation today return the disdain
> 
> 
> What a misfire!
> 
> 
> ______________________________________________________________
> _________
> 
> 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
> 
> 
> 
_______________________________________________________________________

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

Not to  preach, but I have always felt that respect for what has been achieved is a good place to start any conversation.

I am merely asking why some simple steps can't be taken to move the yardsticks a bit.  Not any steps:
the steps I am proposing.

Cheers,
Peter
________________________________________
From: Len Bullard [Len.Bullard@ses-i.com]
Sent: April 16, 2012 4:36 PM
To: Simon St.Laurent; Rushforth, Peter
Cc: liam@w3.org; xml-dev@l...
Subject: RE:  xml:href, xml:rel and xml:type

And so it begins.

The early HTML people disdained SGML as overbuilt and too hard to
understand because they had yet to understand how and why it worked for
the applications to which it had been applied.  The SGML people returned
the disdain but helped them anyway.

Some decades on, as predicted, attempts to reinvent the early work on
hypertext by the SGML community that evolved into the XML community
continue.  At this point, everyone shares A working system so those
attempts have yet to produce a compelling case.   It is somewhat as if
once shown that a Ford A-model could double as a truck, no one needed
anything better.  Cab heat would be nice but who wants to put the fur
traders out of business?

Why no xml:href?   How many systems does it take to change a light bulb?
No one cares while the bulb is lit.

Why bolt a function-type system onto a syntax standard?  (Linking is a
process; not data).

len

-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
Sent: Monday, April 16, 2012 3:15 PM
To: Rushforth, Peter
Cc: liam@w3.org; xml-dev@l...
Subject: Re:  xml:href, xml:rel and xml:type


The early XML folks may have found HTML to be not what they wanted, and
seriously lacking in many respects, and the people driving the HTML
conversation today return the disdain


What a misfire!

 >XML on the web is difficult, so I would say XML has fallen short of 
this goal in at least one respect: it's not a hypermedia format.

It's not an EDI standard either, or a format for mail archives, or a 
format for publishing scientific articles, or sheet music, or browser 
history files, or resumes, or calendars, or museum catalogs, or 
insurance policies, or mapping data. Instead, it's a notation for 
defining all of these. It's a syntax that allows you to layer your own 
vocabulary on top. Hypermedia formats, like all these other things, 
belong in the layer on top.

Michael Kay
Saxonica

Not to worry, Peter.  We've practiced. :)

Essentially, xml:href adds application semantics to the XML specification.
XML abhors application semantics in its specification.  Adding those
violates the simplicity constraint.   Application specifications are free to
do that.  IOW, you are asking the wrong list.  Or maybe not, but the point
is, XML doesn't specify XML applications past what is needed for XML itself.


Functional specifications for inter XML linking are a snap.  Functional
linking to other media types is built into the web.

What is the scope for xml:href linking and how does that differ from what is
currently possible with previously specified technologies?

One compelling argument for functionally-spec'd XML is authoring common
document type collections, eg, TOCs, typed indices, figure/table
collections, etc.   Tbese are human cultural notation types.  Building those
into a system for use by humans is never wrong, IMHO.

len



-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] 
Sent: Monday, April 16, 2012 6:55 PM
To: Len Bullard; Simon St.Laurent
Cc: liam@w3.org; xml-dev@l...
Subject: RE:  xml:href, xml:rel and xml:type

Not to  preach, but I have always felt that respect for what has been
achieved is a good place to start any conversation.

I am merely asking why some simple steps can't be taken to move the
yardsticks a bit.  Not any steps:
the steps I am proposing.

Cheers,
Peter
________________________________________
From: Len Bullard [Len.Bullard@ses-i.com]
Sent: April 16, 2012 4:36 PM
To: Simon St.Laurent; Rushforth, Peter
Cc: liam@w3.org; xml-dev@l...
Subject: RE:  xml:href, xml:rel and xml:type

And so it begins.

The early HTML people disdained SGML as overbuilt and too hard to
understand because they had yet to understand how and why it worked for
the applications to which it had been applied.  The SGML people returned
the disdain but helped them anyway.

Some decades on, as predicted, attempts to reinvent the early work on
hypertext by the SGML community that evolved into the XML community
continue.  At this point, everyone shares A working system so those
attempts have yet to produce a compelling case.   It is somewhat as if
once shown that a Ford A-model could double as a truck, no one needed
anything better.  Cab heat would be nice but who wants to put the fur
traders out of business?

Why no xml:href?   How many systems does it take to change a light bulb?
No one cares while the bulb is lit.

Why bolt a function-type system onto a syntax standard?  (Linking is a
process; not data).

len

-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
Sent: Monday, April 16, 2012 3:15 PM
To: Rushforth, Peter
Cc: liam@w3.org; xml-dev@l...
Subject: Re:  xml:href, xml:rel and xml:type


The early XML folks may have found HTML to be not what they wanted, and
seriously lacking in many respects, and the people driving the HTML
conversation today return the disdain


What a misfire!


_______________________________________________________________________

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

Hi Liam,

> The goal was to put SGML on the Web. It was difficult to use 
> SGML on the Web at the time. 

XML on the web is difficult, so I would say XML has fallen short of this
goal in at least one respect:  it's not a hypermedia format.  You don't have to get 100%
on the exam to be a success, so I'm not saying XML is a failure, but there's room for improvement.  

> The goal was not to replace HTML.
Which has a different goal than XML, obviously.

> 
> Peter - the short answer is that painting the railway engine 
> green won't make more people travel by train. There's no 
> single magic bullet. 

Fair enough.  Making XML into a hypermedia format involves more than links anyway.
But, if the base format does not have links, then only formats which derive from 
a format in the (derivation) tree which defines links will have links.  So the only formats
to have links in XML are those which use xlink.  Does XForms use xlink?  I'm not
saying it should, but to leverage software libraries which do implement links,
it might want to.

> There are barriers that could be lowered 
> a little, but there also has to be incentive, you have to 
> offer things that people already know they want.

I'm interpreting the paucity of support for xlink in XML clients to mean that
there is an unfulfilled need at the XML level.  That's just my interpretation
of course. 

> 
> For trains, it's a perception of a frequent and fast service 
> with no need to book a seat.
> 
> For computer formats it's making something easier than what 
> people currently do - not equally easy, but easier. 

Good point.  

Regarding xml:href, xml:rel and xml:type :

0) XML is not a hypermedia format - it needs links at a minimum to get up to that bar -
1) The XML namespace and its prefix are hardwired onto xml, and so offer an appealing point of entry for the sake of simplicity
2) Information models which don't specifically exclude such attributes appear to allow them
3) They don't prevent use of any other XML construct, as far as I can tell, including xlink.
4) "xml:type" has no equivalent in xlink - no typed links.  I think same for "xml:hreflang".  These aspects support the "Web" (REST) (I think).

Obvious continuing need to crowd-source the benefits and potential barriers. :-)


> > > If "mastery of the Web" _had_ been a goal, XML would have 
> been very 
> > > different, as Jeni Tennyson pointed out in her keynote at 
> XML Prague 
> > > this year.
> 
> I apologise to Jeni for the typo in "Tennison".
> 
> > Yes, I saw the video, but I forget this specific point.  
> Did she say 
> > how it would have been different?
> 
>   ``What might have been is an abstraction
>     Remaining a perpetual possibility
>     Only in a world of speculation.
>     What might have been and what has been
>     Point to one end, which is always present.''

:-)

Cheers,
Peter

>> If that's the case, then I'm sceptical about
>> whether this information belongs in the XML.
> Why are you sceptical?
>
Remember third normal form?

My postcode is RG4 7BS. That's a relationship, between me and where I 
live. If I want to record my postcode in an XML data file, that is the 
way I should record it. If someone wants to use that fact to get 
information about that postcode from a web service provide by the UK 
Post Office, or the Ordnance Survey, or Google, that's a matter for the 
user of the data and/or the application. The address of the web service 
and the domain name of its provider doesn't need to be stored 
redundantly with every postcode. To do so is simply bad normalization; 
and it violates the objectives of normalization, which is to maximize 
potential for change. If the application decides to get its information 
about postcodes from Google rather than from the PostOffice, why should 
that mean changing the address data for every customer?

Michael Kay
Saxonica

On 16 April 2012 15:41, Rushforth, Peter
<Peter.Rushforth@nrcan-rncan.gc.ca> wrote:

>> However, I think
>> the first reaction was to point you towards XLink and XPointer.
>
> Yes, others have pointed that out.  I'm thinking about RESTful use of
> XML.  REST is the basis on which the Web's protocol is designed.
> "typed" links are a fundamental part of REST, I think.
>
> So, my question is, what is the simplest change that could be made
> to XML which would enable its "success" on the web?  My suggestion
> is to insert linking lower down in the XML technology stack than
> what is done by XLink.

I'd encourage you (if you haven't already) to dip into the 1000s of
messages and posts that have been written about XHTML 'vs' non-XML
HTML (HTML5, WHATWG, etc.).

Most of the fire in those exchanges wasn't about linking notations,
but rather around XML's alleged brittleness vs HTML's support for more
lax, tag-soup parsing when the content is partly broken. A preference
amongst Web developers for JSON rather than XML, and Javascript rather
than XQuery/XSLT, is also part of the mix.

http://blog.jclark.com/2010/11/xml-vs-web_24.html and
http://norman.walsh.name/2010/11/17/deprecatingXML give some flavour
of that discussion. Or http://annevankesteren.nl/2007/10/xml5

cheers,

Dan

Hi Dan,

I forked the thread because I think it stands apart from the original topic.

> I'd encourage you (if you haven't already) to dip into the 
> 1000s of messages and posts that have been written about 
> XHTML 'vs' non-XML HTML (HTML5, WHATWG, etc.).
> 

Thanks for the reminders.  I especially liked James' post, which I read
some time ago and re-read just now.

His description is very accurate (would you expect anything less!).

I also believe that there is a need for bridges to be built between the Web
and XML, which follow simple, yet dare I say, hard-wired patterns.

The value of doing so is described in James' post:

"This is not a good thing for either community (and it's why part of my reaction to JSON is "Sigh"). XML misses out by not having the innovation, enthusiasm and traction that the Web developer community brings with it, and the Web developer community misses out by not being able to take advantage of the powerful and convenient technologies that have been built on top of XML over the last decade."

The way forward is also suggested:

"In the short-term, I think the challenge is how to make HTML5 play more nicely with XML. In the longer term, I think the challenge is how to use our collective experience from building the XML stack to create technologies that work natively with HTML, JSON and JavaScript, and that bring to the broader Web developer community some of the good aspects of the modern XML development experience."


> Most of the fire in those exchanges wasn't about linking 
> notations, but rather around XML's alleged brittleness vs 
> HTML's support for more lax, tag-soup parsing when the 
> content is partly broken.


In terms of "playing nicely with XML", I like atompub because it could be a bridge
from presentation markup to data markup (by URI reference, what else ;-).  HTML5 could (in theory) have tags 
(as yet non-existent, I'm just saying) which require feeds for content, basically anything 
that is "a collection of members" could be subject to such markup.

It does not constrain the MIME media type to application/atom+xml - 
content negotiation allows the server to deliver application/json, 
application/gml+xml, application/etc if demanded.  But application/atom+xml
is the "hard-wired" reliable value.  A big part of the value is the
hard-wiredness of it.  

The simple resource model (Collection + Member) together with the simple
representation model (feed + entry) seem abstract enough to have generality
yet hard-wired enough to have simplicity.  The value of the atom format
is that it seems "widely" understood, also slightly hard-wired. Even some 
web browsers seem to vaguely know of atom format, if not the MIME media type.  
I stress vaguely.

While this may seem like an "envelope" to some, I agree, but because
of content negotiation, a client does not need to deal with the envelope 
part if the service supports a more appropriate media type for it. HTML is
an unlikely candidate for that service because the of the presentation 
semantics.  

To bring the topic back to @xml:href, @xml:rel and @xml:type, maybe those are the
means to directly "web-enable" non-atom XML-based formats with some judicious hard-wiring.
Even if atom becomes the spoken dialect between clients and web services, 
there will still be a need for non-HTML hypertext within the atom envelopes.

Cheers,
Peter

> I'm not suggesting that.  I'm suggesting @xml:rel as a way of capturing
> the name of the relationships:
>
> <factory xml:href="http://example.com/willy-wonkas-chocolate-factory/location" xml:rel="location" xml:type="application/xml">
> <name>Willy Wonka's Chocolate Factory</name>
> <products>
> <product xml:href=""http://example.com/willy-wonkas-products/wonka-bar" xml:rel="describedby" xml:type="application/xml"><name>Wonka Bar</name>
> </products>
> </factory
>
Are these href values URIs or URLs? I get the impression, because you're 
talking about REST, that they can be dereferenced. If that's the case, 
then I'm sceptical about whether this information belongs in the XML. 
The identity of a product is not the same as the address of a web 
service that can provide information about the product. There's too much 
muddling of layers going on here. The application should get information 
about products by combining two pieces of information: knowledge of the 
product's identifier, and knowledge of a service that provides 
trustworthy information about products. I don't think it's right to 
bundle those two things inseparably together.

Michael Kay
Saxonica

Hi Mike,

> > I'm not suggesting that.  I'm suggesting @xml:rel as a way of 
> > capturing the name of the relationships:
> >
> > <factory 
> > 
> xml:href="http://example.com/willy-wonkas-chocolate-factory/location" 
> > xml:rel="location" xml:type="application/xml"> <name>Willy Wonka's 
> > Chocolate Factory</name> <products> <product 
> > xml:href=""http://example.com/willy-wonkas-products/wonka-bar" 
> > xml:rel="describedby" xml:type="application/xml"><name>Wonka 
> > Bar</name> </products> </factory
> >
> Are these href values URIs or URLs? I get the impression, 
> because you're talking about REST, that they can be 
> dereferenced. 

Yes they can be dereferenced.

> If that's the case, then I'm sceptical about 
> whether this information belongs in the XML. 

Why are you sceptical?

> The identity of a product is not the same as the address of a 
> web service that can provide information about the product.
> There's too much muddling of layers going on here. The 
> application should get information about products by 
> combining two pieces of information: knowledge of the 
> product's identifier, and knowledge of a service that 
> provides trustworthy information about products. I don't 
> think it's right to bundle those two things inseparably together.

I completely agree.  xml:href is a URI that is meant to be
dereferenced, if desired by the client.

I did not show a factory or product identifier, perhaps as an oversight, but
more so as to not talk about them.

Cheers,
Peter

On 4/16/12 3:22 PM, Rushforth, Peter wrote:
> Hi Liam,
>
>> The goal was to put SGML on the Web. It was difficult to use SGML
>> on the Web at the time.
>
> XML on the web is difficult, so I would say XML has fallen short of
> this goal in at least one respect:  it's not a hypermedia format.
> You don't have to get 100% on the exam to be a success, so I'm not
> saying XML is a failure, but there's room for improvement.

You're being kind.  XML failed in its original mission, and its original 
set of markup, style, and linking didn't work out.

XML failed.  It failed in the spectacular way that led to all kinds of 
other successes.  It didn't change the Web the way it planned, but it 
made people reevaluate practically everything they were doing.

After a few missteps into RPC, XML made REST (and now RESTful 
hypermedia, though rarely XLinked) plausible at a time when people 
couldn't imagine how something so simple-minded might work.  After a few 
battles with relational database purists, XML made it clear that more 
chaotic structures had a place in data interchange and I suspect freed 
things up enough for the NoSQL movement to find traction.

In its document homeland, XML's simplifications made it easier for 
markup-based toolchains to thrive and grow, enabling ever more content 
to be processed more flexibly.

The early XML folks may have found HTML to be not what they wanted, and 
seriously lacking in many respects, and the people driving the HTML 
conversation today return the disdain.  XLink and XPointer have 
statistically insignificant user bases, so clearly something misfired.

What a misfire!

Thanks,
-- 
Simon St.Laurent
http://simonstl.com/

And so it begins.

The early HTML people disdained SGML as overbuilt and too hard to
understand because they had yet to understand how and why it worked for
the applications to which it had been applied.  The SGML people returned
the disdain but helped them anyway.

Some decades on, as predicted, attempts to reinvent the early work on
hypertext by the SGML community that evolved into the XML community
continue.  At this point, everyone shares A working system so those
attempts have yet to produce a compelling case.   It is somewhat as if
once shown that a Ford A-model could double as a truck, no one needed
anything better.  Cab heat would be nice but who wants to put the fur
traders out of business?

Why no xml:href?   How many systems does it take to change a light bulb?
No one cares while the bulb is lit.

Why bolt a function-type system onto a syntax standard?  (Linking is a
process; not data).

len

-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com] 
Sent: Monday, April 16, 2012 3:15 PM
To: Rushforth, Peter
Cc: liam@w3.org; xml-dev@l...
Subject: Re:  xml:href, xml:rel and xml:type


The early XML folks may have found HTML to be not what they wanted, and 
seriously lacking in many respects, and the people driving the HTML 
conversation today return the disdain


What a misfire!

Hi Len,

> 
> It's a side issue but what relationship is explicit by enclosure?  
> 
> IS-A or HAS-A?
> 
> Seems simple enough but this is where this has fallen apart 
> in the past.
> We think it is a simple, easy to recognize relationship and 
> it turns out what we think we know just ain't so.  
> 
> The evidence only supports HAS-A.

OK, I don't know.  I always thought of it as "I use it any way I
see fit", but the mechanism is static.  It is the mechanism that
yields some interoperability though.  It's a hard-wired convention.

> 
> A post-2000 discussion of architectural forms reinforces the 
> basic dilemma of web technology:  it is a system attempting 
> to be THE systems of systems and I've no knowledge of any 
> system succeeding at that for
> more than one turn of the wheel.

Sorry. Are you talking about architectural forms, or the web?

>  A lot of nonsense can be avoided by
> saying "We are only spec'ing this for the web.  Full stop." 
> 
> And then not nudging or winking that the only system of 
> concern for others is the web.  That is the nonsense that 
> defeats separation of concerns.

Is the proposal for xml:href, xml:rel and xml:type is
such a nudge or a wink? _I_ think it's a proposal for a simple hard-wired 
convention, something analogous to the nesting of elements implying a relationship
between whatever those elements are representing.

Cheers,
Peter

As dull and tedious and odious as it would be, I suppose someone should
tell without names what the history of SGML/XML is and why it is applied
in all kinds of data storage and retrieval systems including hypermedia
and hypertext.

The point in short is, XML isn't a format.   It is a system,
specifically, a syntax system for creating formats used by other
systems, notably, hypertext systems (depending on what you spec,
hypertext is a superset of hypermedia; one can argue otherwise, but only
by stepping out a level of system abstraction).   It is these layers of
system abstractions and systems applied to create
functionally-delineated systems (Guns A Go Go) that confuse people who
haven't been through the whole nine yards of history in warping the web.

XML is a part/system of a hypermedia system.   HTML is part/system of a
hypertext system.  How many systems does it take to turn on a lightbulb?

BTW: the early SGML hypermedia systems were more like you are looking
for.  This is a case where we went from complex advanced systems to
simple basic systems in order to achieve scale.   A question of some
interest is to explore what aspects of scale were, in the minds of the
designers, unachievable with SGML prior to XML.   But the idea that SGML
cannot be used in large scale open hypermedia systems is false.   That
it hasn't been is historically true.   Separation of concerns is at the
top of the list why that is historically true and true when attempting
to implement all of the systems required by multiple people in multiple
locations working on different projects that share some requirements.
There are also some ego bruising politics but like most politics, they
now only matter to those who were first person shooters at the rodeo.

Forget the abstract notion of relationships for a moment.  How many ways
are there to link into and out of a 

file/entity/blob/database/map/image/video/real-time-3D/bag-o-bits?

Once you tackle that problem, you have an understanding where things
stood in circa 1988/89 when we began to discuss time as well.

len

-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] 
Sent: Monday, April 16, 2012 2:22 PM
To: liam@w3.org
Cc: xml-dev@lists.xml.org
Subject: RE:  xml:href, xml:rel and xml:type

Hi Liam,

> The goal was to put SGML on the Web. It was difficult to use 
> SGML on the Web at the time. 

XML on the web is difficult, so I would say XML has fallen short of this
goal in at least one respect:  it's not a hypermedia format.  You don't
have to get 100%
on the exam to be a success, so I'm not saying XML is a failure, but
there's room for improvement.  

> The goal was not to replace HTML.
Which has a different goal than XML, obviously.

> 
> Peter - the short answer is that painting the railway engine 
> green won't make more people travel by train. There's no 
> single magic bullet. 

Fair enough.  Making XML into a hypermedia format involves more than
links anyway.
But, if the base format does not have links, then only formats which
derive from 
a format in the (derivation) tree which defines links will have links.
So the only formats
to have links in XML are those which use xlink.  Does XForms use xlink?
I'm not
saying it should, but to leverage software libraries which do implement
links,
it might want to.

> There are barriers that could be lowered 
> a little, but there also has to be incentive, you have to 
> offer things that people already know they want.

I'm interpreting the paucity of support for xlink in XML clients to mean
that
there is an unfulfilled need at the XML level.  That's just my
interpretation
of course. 

> 
> For trains, it's a perception of a frequent and fast service 
> with no need to book a seat.
> 
> For computer formats it's making something easier than what 
> people currently do - not equally easy, but easier. 

Good point.  

Regarding xml:href, xml:rel and xml:type :

0) XML is not a hypermedia format - it needs links at a minimum to get
up to that bar -
1) The XML namespace and its prefix are hardwired onto xml, and so offer
an appealing point of entry for the sake of simplicity
2) Information models which don't specifically exclude such attributes
appear to allow them
3) They don't prevent use of any other XML construct, as far as I can
tell, including xlink.
4) "xml:type" has no equivalent in xlink - no typed links.  I think same
for "xml:hreflang".  These aspects support the "Web" (REST) (I think).

Obvious continuing need to crowd-source the benefits and potential
barriers. :-)


> > > If "mastery of the Web" _had_ been a goal, XML would have 
> been very 
> > > different, as Jeni Tennyson pointed out in her keynote at 
> XML Prague 
> > > this year.
> 
> I apologise to Jeni for the typo in "Tennison".
> 
> > Yes, I saw the video, but I forget this specific point.  
> Did she say 
> > how it would have been different?
> 
>   ``What might have been is an abstraction
>     Remaining a perpetual possibility
>     Only in a world of speculation.
>     What might have been and what has been
>     Point to one end, which is always present.''

:-)

Cheers,
Peter

_______________________________________________________________________

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

Hi Mike,

> 
> 
> On 13/04/2012 13:36, Rushforth, Peter wrote:
> >
> >
> > I am interested in RESTful applications, and in thinking about the 
> > space, I have come to think that XML, while wonderful for creating 
> > your own domain specific vocabulary, also suffers from that very 
> > strength:  too many re-inventions of the same thing 
> (because its so easy to reinvent) leads to no 
> standardization/interoperability at all.
> So why reinvent XLink?
> 
> I've always had the view that data models generally consist 
> of objects (elements), attributes, and relationships, and if 
> XML allows you to dream up your own names for your elements 
> and attributes then it should also allow you to use your own 
> name for your relationships. 

One of the ways that XML allows (forces?) us to model a relationship is with 
enclosing elements:

<factory><name>Willy Wonka's Chocolate Factory</name><location>England</location></factory>


> Why should we use the same name 
> for the relationship between a product and its manufacturer 
> as we use for the relationship between a factory and its 
> geographical location?

I'm not suggesting that.  I'm suggesting @xml:rel as a way of capturing
the name of the relationships:

<factory xml:href"http://example.com/willy-wonkas-chocolate-factory/location" xml:rel="location" xml:type="application/xml">
<name>Willy Wonka's Chocolate Factory</name>
<products>
<product xml:href=""http://example.com/willy-wonkas-products/wonka-bar" xml:rel="describedby" xml:type="application/xml"><name>Wonka Bar</name>
</products>
</factory

Note that the semantics of "@xml:type" are different from those of xlink:type.

But I don't think you meant that, I think you meant xlink made a mistake, 
don't push xml to do the same thing.

> 
> I think that's why XLink failed, and I don't see any 
> difference in your proposal.

I agree it's a little similar.  But I'm suggesting an 80/20 rule-based tweak to add
hypertext compatible with REST.  

1) no namespace declaration is required.
2) semantics of xml:href, xml:rel and xml:type are defined by external rfcs that work on the web.
3) it's 'inherited' by all of xml, I'm hoping in a backwards-compatible way. I'd like to hear 
what the incompatibilities might be.  I tried a stylesheet on an XML document using these attributes
and they seem to be copied by xsl:copy-of without complaint.  Where else should I look?

> 
> Now, data typing is another matter: it would be nice if 
> attributes containing dates, integers, or URIs were 
> recognizable as such without recourse to a schema. But 
> forcing all URIs to be called xlink:href is as crazy as 
> forcing all dates to be called date.

xml:lang ?  The value of this is in its static name.  Doesn't prevent you
from creating any amount of language-semantics-specific markup in your documents, using
your own nomenclature.

Although I guess that's where xlink ran into trouble, if I interpret David Carlisle's later
email: 

<snip>
Consider xhtml that came under a lot of pressure when it was being designed to use xlink links (which were being designed at the same time) but it would have meant that you could not use <img src="foo"/> it would have to be <img xlink:href="foo" xlinl:type="simple" xlink:show="embed"/> You could not go <a href="bar.html">.. had to go <a xlink:href="bar.html" type="simple">...
</snip>

Seems to me to be forcing the "xml" way of doing things on something that was already workable.
I would not do that, my opinion is there's nothing forcing people to use xml:lang etc, but
when they are built into tools, like xslt and xpath, it does improve the developer experience.

Cheers,
Peter

On 16/04/2012 13:21, Mike Sokolov wrote:
 > I'm having some difficulty seeing the value in a rule that would
 > form links for elements with three vowels in their names.  Maybe if
 > you had a better example, the world would flock to implement this?
 > Seriously - what are you on about? Sorry for being dim, but it
 > sounds like it might be interesting, and I just don't get it.

The point is that xlinks major (fatal really) failing is that it forces
attribute names on the vocabularies that use it. (Its bad enough that
xml:id forces a name but the issues are worse with link attributes)


Consider xhtml that came under a lot of pressure when it was being
designed to use xlink links (which were being designed at the same time)
but it would have meant that you could not use <img src="foo"/> it would
have to be <img xlink:href="foo" xlinl:type="simple" xlink:show="embed"/>
You could not go <a href="bar.html">.. had to go <a
xlink:href="bar.html" type="simple">...

architectural forms which pre-dated xlink from SGML had a much more
extensive vocabulary that allowed you to impose linking semantics on
_existing_ markup without the markup having to change.

So you want to be able to say things like

a/href is a normal link, img/@src is an embed link.

But the recognition patterns might need to be more advanced such as
Liam's somewhat extreme example.

David
(I never actually used architectural forms:-)

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________

Hi Liam,

Thanks for your reply.

> 
> > As I understand it, mastery of the web was a goal of XML, 
> so I'm just 
> > dreaming a little.
> 
> It was not a goal of XML.
> 
> The primary goal of XML was getting existing SGML documents 
> and work-flows onto the Web. The work was originally called Web SGML.

From "http://www.w3.org/TR/xml/#sec-origin-goals"

The design goals for XML are:

1. XML shall be straightforwardly usable over the Internet.

OK, this is not "mastery of the web", but the Web is an important
application of the internet.  

> Your comment did I think reach the XML Core Working Group; 
> the group meets two or three times a month for half an hour, 
> so don't expect an immediate response :-)

Sorry, I should have posted here in the first place anyway.

> However, I think 
> the first reaction was to point you towards XLink and XPointer.

Yes, others have pointed that out.  I'm thinking about RESTful use of
XML.  REST is the basis on which the Web's protocol is designed.
"typed" links are a fundamental part of REST, I think.
  
So, my question is, what is the simplest change that could be made
to XML which would enable its "success" on the web?  My suggestion
is to insert linking lower down in the XML technology stack than
what is done by XLink.

Others also predicted that my suggestion would not be 'popular'.
I'm OK with that, but I wanted to hear from the technology implementers
of what would break if such a change was made.  
> 
> If "mastery of the Web" _had_ been a goal, XML would have 
> been very different, as Jeni Tennyson pointed out in her 
> keynote at XML Prague this year.

Yes, I saw the video, but I forget this specific point.  Did she say
how it would have been different? 

> To answer a more explicit question (from a personal 
> perspective), the cost of introducing xml:href would be 
> risking breaking existing XML systems,

I've tried putting these
attributes on XML source and running XSLT against them, no
obvious problems.  I found no support for XLink in my XML IDE. 

> which are far more 
> likely to work with xlink:href. 

I know there are vocabulary standards which use xlink.  Of course that
means there are processors which use it too.  I think that if you need
the power of describing links semantically etc, you should use it.  But
not everyone needs this power.  For that matter, one is not obliged to
use XLink, you can "roll your own" linking scheme, which your own processors
can leverage.

> And there's no clear benefit.

OK, I think there is.  I think that having a simple standard that
does not have to be declared by the user would allow linking of XML documents
"on the web", with design aligned with that of the web, hence xml:type and possibly xml:hreflang.

BTW, I think the JSON community is considering the same problem:
http://www.mnot.net/blog/2011/11/25/linking_in_json


> 
> The biggest problem I see with XLink is that it did not 
> address "link discovery through architectural forms" - the 
> process of saying, "in this XML vocabulary, the "cf" 
> attribute on any element with three vowels in the element 
> name is a link constructed by using the template
>   concat(@cf, "?", local-name(), "=", .)

I have been wondering about how to use URI templates in XML:
http://www.rfc-editor.org/rfc/rfc6570.txt

Is this a similar idea?

Cheers,
Peter

People don't remember (because there were none) that the Cambrian Moment
was many millions of years long.

If the W3C puts up policy objections to an official history being
written, remind them that if they don't, someone like me will write it
and put it on the web. ;)

len

-----Original Message-----
From: Liam R E Quin [mailto:liam@w3.org] 
Sent: Monday, April 16, 2012 11:59 AM
To: Rushforth, Peter
Cc: xml-dev@lists.xml.org
Subject: RE:  xml:href, xml:rel and xml:type

On Mon, 2012-04-16 at 13:41 +0000, Rushforth, Peter wrote:

> 1. XML shall be straightforwardly usable over the Internet.
> 
> OK, this is not "mastery of the web", but the Web is an important
> application of the internet.

The goal was to put SGML on the Web. It was difficult to use SGML on the
Web at the time. The goal was not to replace HTML.

We never expected such widespread adoption. One feature of SGML remained
in the XML spec because we feared we might lose as many as a dozen
existing SGML users if we removed it.

Peter - the short answer is that painting the railway engine green won't
make more people travel by train. There's no single magic bullet. There
are barriers that could be lowered a little, but there also has to be
incentive, you have to offer things that people already know they want.

For trains, it's a perception of a frequent and fast service with no
need to book a seat.

For computer formats it's making something easier than what people
currently do - not equally easy, but easier. There might be some
traction in
<a http://example.org/>...</a>
for example, but that's not XML.

Grumpy pre-coffee responses follow... :-)

> Yes, others have pointed that out.  I'm thinking about RESTful use of
> XML.  REST is the basis on which the Web's protocol is designed.
> "typed" links are a fundamental part of REST, I think.

It's lucky that XPointer and XLink do not preclude such use then :-)
(and yes, I read Roy's thesis when it was published)

> So, my question is, what is the simplest change that could be made
> to XML which would enable its "success" on the web?

The simplest change is no change - XML is a success and met its goals.

If you mean, get XML used by people in preference to HTML...
* there's no direct way to get JavaScript used in plain XML
* the HTML DOM doesn't deal well with XML namespaces
* CSS doesn't deal well with XML namespaces
* XML cares about syntax errors and so do Web browsers; in principle
  Web browsers are not forbidden from correcting such errors as long as
  they don't claim the input was well-formed XML, but in practice the
  Web developer communities and the XML communities have remained very
  separate and the motivation to improve the XML experience in the
  Web browser is limited.  Namespaces in CSS became a recommendation
  last year, go figure.
 
> I wanted to hear from the technology implementers
> of what would break if such a change was made.

I don't see Web browsers changing for it - they don't support XLink
either.


> > If "mastery of the Web" _had_ been a goal, XML would have 
> > been very different, as Jeni Tennyson pointed out in her 
> > keynote at XML Prague this year.

I apologise to Jeni for the typo in "Tennison".

> Yes, I saw the video, but I forget this specific point.  Did she say
> how it would have been different?

  ``What might have been is an abstraction
    Remaining a perpetual possibility
    Only in a world of speculation.
    What might have been and what has been
    Point to one end, which is always present.''


> > To answer a more explicit question (from a personal 
> > perspective), the cost of introducing xml:href would be 
> > risking breaking existing XML systems,
> 
> I've tried putting these
> attributes on XML source and running XSLT against them, no
> obvious problems.

Names in the "xml" namespace are reserved, but the specs don't say
exactly what this means.

> I know there are vocabulary standards which use xlink.  Of course that
> means there are processors which use it too.

SVG is an example.

> > The biggest problem I see with XLink is that it did not 
> > address "link discovery through architectural forms" - the 
> > process of saying, "in this XML vocabulary, the "cf" 
> > attribute on any element with three vowels in the element 
> > name is a link constructed by using the template
> >   concat(@cf, "?", local-name(), "=", .)
> 
> I have been wondering about how to use URI templates in XML:
> http://www.rfc-editor.org/rfc/rfc6570.txt
> 
> Is this a similar idea?

Almost; here is a concrete example in that spirit:

<?link path="//person" name="." uri="http://example.org/people/$name" ?>

You'd put this in the DTD (I know, Web browsers don't fetch DTDs because
of the FUD over "billion laughs", an attack also present in JavaScript,
and HTLM 5 deprecates processing instructions, but go with the flow
here...)

Now <person>daniel</person> would turn into
http://example.org/people/daniel

and a user agent could traverse the link based on some user action.

In a cooperative world :-) path would be any XPath 3 expression, but
only a few weeks ago I heard Web developers saying "XPath just reinvents
selectors and offers no new functionality, but unlike selectors cannot
be implemented efficiently" and with reasoning like that we've got a
long way to go.

I don't actually mean to be defeatist - it's a long road but a number of
people (including me) are trying to walk it, one step at a time, despite
the thorns in the path.

It took a decade for the Web developer world to adopt CSS. Now there's a
movement for people to be able to define their own elements in HTML. The
concepts are slowly coming.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/


_______________________________________________________________________

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

On Mon, 2012-04-16 at 13:41 +0000, Rushforth, Peter wrote:

> 1. XML shall be straightforwardly usable over the Internet.
> 
> OK, this is not "mastery of the web", but the Web is an important
> application of the internet.

The goal was to put SGML on the Web. It was difficult to use SGML on the
Web at the time. The goal was not to replace HTML.

We never expected such widespread adoption. One feature of SGML remained
in the XML spec because we feared we might lose as many as a dozen
existing SGML users if we removed it.

Peter - the short answer is that painting the railway engine green won't
make more people travel by train. There's no single magic bullet. There
are barriers that could be lowered a little, but there also has to be
incentive, you have to offer things that people already know they want.

For trains, it's a perception of a frequent and fast service with no
need to book a seat.

For computer formats it's making something easier than what people
currently do - not equally easy, but easier. There might be some
traction in
<a http://example.org/>...</a>
for example, but that's not XML.

Grumpy pre-coffee responses follow... :-)

> Yes, others have pointed that out.  I'm thinking about RESTful use of
> XML.  REST is the basis on which the Web's protocol is designed.
> "typed" links are a fundamental part of REST, I think.

It's lucky that XPointer and XLink do not preclude such use then :-)
(and yes, I read Roy's thesis when it was published)

> So, my question is, what is the simplest change that could be made
> to XML which would enable its "success" on the web?

The simplest change is no change - XML is a success and met its goals.

If you mean, get XML used by people in preference to HTML...
* there's no direct way to get JavaScript used in plain XML
* the HTML DOM doesn't deal well with XML namespaces
* CSS doesn't deal well with XML namespaces
* XML cares about syntax errors and so do Web browsers; in principle
  Web browsers are not forbidden from correcting such errors as long as
  they don't claim the input was well-formed XML, but in practice the
  Web developer communities and the XML communities have remained very
  separate and the motivation to improve the XML experience in the
  Web browser is limited.  Namespaces in CSS became a recommendation
  last year, go figure.
 
> I wanted to hear from the technology implementers
> of what would break if such a change was made.

I don't see Web browsers changing for it - they don't support XLink
either.


> > If "mastery of the Web" _had_ been a goal, XML would have 
> > been very different, as Jeni Tennyson pointed out in her 
> > keynote at XML Prague this year.

I apologise to Jeni for the typo in "Tennison".

> Yes, I saw the video, but I forget this specific point.  Did she say
> how it would have been different?

  ``What might have been is an abstraction
    Remaining a perpetual possibility
    Only in a world of speculation.
    What might have been and what has been
    Point to one end, which is always present.''


> > To answer a more explicit question (from a personal 
> > perspective), the cost of introducing xml:href would be 
> > risking breaking existing XML systems,
> 
> I've tried putting these
> attributes on XML source and running XSLT against them, no
> obvious problems.

Names in the "xml" namespace are reserved, but the specs don't say
exactly what this means.

> I know there are vocabulary standards which use xlink.  Of course that
> means there are processors which use it too.

SVG is an example.

> > The biggest problem I see with XLink is that it did not 
> > address "link discovery through architectural forms" - the 
> > process of saying, "in this XML vocabulary, the "cf" 
> > attribute on any element with three vowels in the element 
> > name is a link constructed by using the template
> >   concat(@cf, "?", local-name(), "=", .)
> 
> I have been wondering about how to use URI templates in XML:
> http://www.rfc-editor.org/rfc/rfc6570.txt
> 
> Is this a similar idea?

Almost; here is a concrete example in that spirit:

<?link path="//person" name="." uri="http://example.org/people/$name" ?>

You'd put this in the DTD (I know, Web browsers don't fetch DTDs because
of the FUD over "billion laughs", an attack also present in JavaScript,
and HTLM 5 deprecates processing instructions, but go with the flow
here...)

Now <person>daniel</person> would turn into
http://example.org/people/daniel

and a user agent could traverse the link based on some user action.

In a cooperative world :-) path would be any XPath 3 expression, but
only a few weeks ago I heard Web developers saying "XPath just reinvents
selectors and offers no new functionality, but unlike selectors cannot
be implemented efficiently" and with reasoning like that we've got a
long way to go.

I don't actually mean to be defeatist - it's a long road but a number of
people (including me) are trying to walk it, one step at a time, despite
the thorns in the path.

It took a decade for the Web developer world to adopt CSS. Now there's a
movement for people to be able to define their own elements in HTML. The
concepts are slowly coming.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

It's a side issue but what relationship is explicit by enclosure?  

IS-A or HAS-A?

Seems simple enough but this is where this has fallen apart in the past.
We think it is a simple, easy to recognize relationship and it turns out
what we think we know just ain't so.  

The evidence only supports HAS-A.

A post-2000 discussion of architectural forms reinforces the basic
dilemma of web technology:  it is a system attempting to be THE systems
of systems and I've no knowledge of any system succeeding at that for
more than one turn of the wheel.   A lot of nonsense can be avoided by
saying "We are only spec'ing this for the web.  Full stop." 

And then not nudging or winking that the only system of concern for
others is the web.  That is the nonsense that defeats separation of
concerns.

len

-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] 
Sent: Monday, April 16, 2012 10:04 AM
To: Michael Kay; xml-dev@lists.xml.org
Subject: RE:  xml:href, xml:rel and xml:type

One of the ways that XML allows (forces?) us to model a relationship is
with 
enclosing elements:

<factory><name>Willy Wonka's Chocolate
Factory</name><location>England</location></factory>

On 4/15/2012 2:56 PM, Liam R E Quin wrote:
> The biggest problem I see with XLink is that it did not address "link
> discovery through architectural forms" - the process of saying, "in this
> XML vocabulary, the "cf" attribute on any element with three vowels in
> the element name is a link constructed by using the template
>    concat(@cf, "?", local-name(), "=", .)
> I could see great value in such a specification if I thought anyone
> would implement and use it.

I'm having some difficulty seeing the value in a rule that would form 
links for elements with three vowels in their names.  Maybe if you had a 
better example, the world would flock to implement this?  Seriously - 
what are you on about? Sorry for being dim, but it sounds like it might 
be interesting, and I just don't get it.

-Mike

On 15 April 2012 20:56, Liam R E Quin <liam@w3.org> wrote:
> On Fri, 2012-04-13 at 12:59 +0000, Rushforth, Peter wrote:
>> [...]
>
>> As I understand it, mastery of the web was a goal of
>> XML, so I'm just dreaming a little.
>
> It was not a goal of XML.
>
> The primary goal of XML was getting existing SGML documents and
> work-flows onto the Web. The work was originally called Web SGML.

Talking of origins and goals (and btw c.f.
http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-origin-goals )

...wouldn't it be nice if W3C Member-only archives from the original
XML days could be opened up?

Maybe after 100 years? 50? 20?

Perhaps the only way to do this 'by the book' in terms of expectations
of the original WG participants, would be for W3C to all declare
planet Earth a W3C Member and all it's residents as acting
representatives of that Member. But I'm sure that other less dramatic
mechanisms could be explored, so long as they were respectful of the
constraints and intentions of the original groups (including those who
are no longer with us). Perhaps 15 years is a reasonable period? Later
work isn't so troubled by this as W3C now does much more in public,
but the early XML (and also RDF) design discussions are frustratingly
hard to cite or share.

I ask as I've been talking with Max (cc:'d) lately about proposing a
W3C Community Group (see http://www.w3.org/community/ ) on Web
History, and I've been wondering whether working up such a proposal
(for eventual public release of certain W3C Member-only archives)
would be a feasible and useful work item. Would anyone be interested
in exploring this and working through the details?

cheers,

Dan

On 13/04/2012 13:36, Rushforth, Peter wrote:
>
>
> I am interested in RESTful applications, and in thinking about the space, I have come
> to think that XML, while wonderful for creating your own domain specific vocabulary,
> also suffers from that very strength:  too many re-inventions of the same thing (because
> its so easy to reinvent) leads to no standardization/interoperability at all.
So why reinvent XLink?

I've always had the view that data models generally consist of objects 
(elements), attributes, and relationships, and if XML allows you to 
dream up your own names for your elements and attributes then it should 
also allow you to use your own name for your relationships. Why should 
we use the same name for the relationship between a product and its 
manufacturer as we use for the relationship between a factory and its 
geographical location?

I think that's why XLink failed, and I don't see any difference in your 
proposal.

Now, data typing is another matter: it would be nice if attributes 
containing dates, integers, or URIs were recognizable as such without 
recourse to a schema. But forcing all URIs to be called xlink:href is as 
crazy as forcing all dates to be called date.

Michael Kay
Saxonica

On Sun, 2012-04-15 at 23:51 +0200, Dan Brickley wrote:

> Talking of origins and goals (and btw c.f.
> http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-origin-goals )

Yup, although the original poster's question was more about the politics
behind those goals I think...

> ...wouldn't it be nice if W3C Member-only archives from the original
> XML days could be opened up?

Yes. Unfortunately, we can't get everyone's permission, as not all
participants are alive today (as you indeed implied in your message).
But we might be able to get permission from all who are alive and from
the families/heirs of others.

> Perhaps the only way to do this 'by the book' in terms of expectations
> of the original WG participants, would be for W3C to all declare
> planet Earth a W3C Member and all it's residents as acting
> representatives of that Member.

I don't think that would qualify as meeting their/our expectations.
Probably the W3C Member Agreement holds, and W3C/ERCIM/MIT/Keio/INRIA
copyright would hold, in which case maybe it's a matter of contacting
people and asking them to agree, out of decency's sake at least. People
write things very differently in a closed group than in a public group.

> I ask as I've been talking with Max (cc:'d) lately about proposing a
> W3C Community Group (see http://www.w3.org/community/ ) on Web
> History, and I've been wondering whether working up such a proposal
> (for eventual public release of certain W3C Member-only archives)
> would be a feasible and useful work item. Would anyone be interested
> in exploring this and working through the details?

Although it's interesting I know I'm also pretty maxed out... (sorry
Max!) but I'm willing to help to the extent I can.

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

On Fri, 2012-04-13 at 12:59 +0000, Rushforth, Peter wrote:
> [...]

> As I understand it, mastery of the web was a goal of
> XML, so I'm just dreaming a little.

It was not a goal of XML.

The primary goal of XML was getting existing SGML documents and
work-flows onto the Web. The work was originally called Web SGML.

Your comment did I think reach the XML Core Working Group; the group
meets two or three times a month for half an hour, so don't expect an
immediate response :-) However, I think the first reaction was to point
you towards XLink and XPointer.

If "mastery of the Web" _had_ been a goal, XML would have been very
different, as Jeni Tennyson pointed out in her keynote at XML Prague
this year.

To answer a more explicit question (from a personal perspective), the
cost of introducing xml:href would be risking breaking existing XML
systems, which are far more likely to work with xlink:href. And there's
no clear benefit.

The biggest problem I see with XLink is that it did not address "link
discovery through architectural forms" - the process of saying, "in this
XML vocabulary, the "cf" attribute on any element with three vowels in
the element name is a link constructed by using the template
  concat(@cf, "?", local-name(), "=", .)

I could see great value in such a specification if I thought anyone
would implement and use it.

Best,

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Michael Hopwood wrote:
> Hi all,
> 
>  
> 
> I’m looking for a quick and simple method to transform XMP files into 
> well-formed XML, 

 From a quick look at
http://en.wikipedia.org/wiki/Extensible_Metadata_Platform,
it looks like XMP is RDF/XML.  (However, I can't tell if my quick look
caused me to miss something saying that XMP might also be written out
something other than RDF/XML.)

If is always RDF/XML, then XMP already is well-formed XML.  (Make sure
you know what "well-formed" does, and doesn't, mean for XML.)  It sounds
like you really meant "valid" (against some schema or DTD).

 > possibly according to an extremely simplified schema
> (i.e. effectively a root node and a list of allowed elements from 
> selected namespaces, all with cardinality 0-n).
> 
>  
> 
> The use case here is to import XMP data into an XSLT engine I’m using, 
> but the existing software can’t handle the RDF/XML of the raw XMP.

You probably want an RDF reader, not a general-purpose XML tool.  When
RDF is serialized into RDF/XML, there are lots of options (lots of
variation in syntax that mean exactly the same thing, but have quite
different XML structure).

Unless you know for sure that only certain syntactic options will be
used, you'd have to handle the multiple RDF/XML options, and that's not
easy in XSLT (or at least not in a single-step transform).


> Since the XMP is relatively flat, I thought there might be a standard or 
> at least well-known way to get this stuff into ...

The standard way to get RDF/XML into memory is to use a real RDF/XML
reader (as opposed to trying to do it with XSL).  A real RDF/XML reader
would already handle all those syntactic variations, and leave you with
the same structures in memory regardless of which syntactic option was
chosen when the RDF/XML was created.


 > a very simple XML form,
 > from whence it could be input into my XSLT engine (which auto-detects
 > the “schema” of the input data before creating an XSLT to transform it
 > and future uploads to a new schema).

Then, you could probably use the RDF/XML reader tool to write out XML
for input to your XSLT transform.

Or you might be able to use the RDF/XML reader tool to write the
data back out into RDF/XML, but using only known subset of the
possible syntactic variations, so that your XSLT transform only has
to handle those variations.


Daniel

> From: Toby Considine [mailto:tobyconsidine@gmail.com] On 
> Subject: RE:  xml:href, xml:rel and xml:type
> 
> And then there is the issue of declaring special purpose XML 
> lexicons. 

Please clarify.  I think this is an important point, but I'm 
not sure we understand the same thing by it.

> Just as I need a mime type for traditional 
> references, and one needs an application type for, say, the 
> "mailto" type link, 

This is a URI scheme I think.  What is it about xml:href which
would not accommodate such a URI?

> there should, of ging down this path, be 
> a place to create/register additional application-namespace 
> types on the references.

Nothing about xml:href, xml:rel and xml:type imply that the full
expressive power of xml is unavailable to the document designer, I think.  

In fact, if these attributes don't fit the need, don't use them.

> 
> In my recent work, I have wrestled with classes of 
> calendar/schedule feeds, and how links to them should be 
> represented. 

> If these are guides to service end points, there 
> should be some way to distinguish and select between a list 
> of them. 

Going back to the expressive power of XML, use that if you need to.

> The idea of a "mini-wsdl" for an array of xlinks w/I 
> a larger xml document, though, threatens to be like a 
> monkfish, i.e. a relatively small creature able to swallow a 
> large goose. The monkfish is hideous.
> After swallowing it has to lie on the bottom for a week or 
> month to digest. 

Interesting analogy!

Cheers,
Peter

Hi Toby,

Thanks for your response. I don't think I understand your message.

I'm not talking about addressing within a document but between documents,
on the web, using URIs. 

I don't think XPath is in scope in other words.

Cheers,
Peter



> -----Original Message-----
> From: Toby Considine [mailto:tobyconsidine@gmail.com] On 
> Behalf Of Toby Considine
> Sent: April 13, 2012 09:54
> To: 'Andrew Welch'; Rushforth, Peter
> Cc: xml-dev@lists.xml.org
> Subject: RE:  xml:href, xml:rel and xml:type
> 
> If one were to go down this path, relative addressing, as in 
> xpath, would need to be in the mix.
> 
> I find that when I use these constructs, though, I confuse users.
> 
> 
> "If something is not worth doing, it`s not worth doing well" 
> - Peter Drucker
> 
> Toby Considine
> TC9, Inc
> TC Chair: oBIX & WS-Calendar
> TC Editor: EMIX, EnergyInterop
> U.S. National Inst. of Standards and Tech. Smart Grid 
> Architecture Committee
> 
>   
> Email: Toby.Considine@gmail.com
> Phone: (919)619-2104
> http://www.tcnine.com/
> blog: www.NewDaedalus.com
> 
> 

On 13/04/2012 13:36, Rushforth, Peter wrote:
> Hi there,
>
> @xml:href

As far as I understand your suggestion, having built in link semantics
was part of the original 3-part plan for XML (along with styling)
but that's xlink:href rather than xml:href. I can't see that adding
another standardised href attribute in addition to xlink's would be that
popular (especially given that xlink isn't exactly the most successful
part of xml)

David



________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________

> So that makes me wonder if
> XML would benefit from a _single_ simple link standard, inherited by all XML vocabularies
> in the same manner as xml:base,  xml:lang .

Just checking as you didn't mention it - are you aware of xlink:

http://www.w3.org/TR/xlink/

Usually when this question comes up, the answer is that linking is
done in a different layer to the xml (the presentation layer).


-- 
Andrew Welch
http://andrewjwelch.com

> From: David Carlisle [mailto:davidc@nag.co.uk] 
> Subject: Re:  xml:href, xml:rel and xml:type
> 
> On 13/04/2012 13:36, Rushforth, Peter wrote:
> > Hi there,
> >
> > @xml:href
> 
> As far as I understand your suggestion, having built in link 
> semantics was part of the original 3-part plan for XML (along 
> with styling) but that's xlink:href rather than xml:href. I 
> can't see that adding another standardised href attribute in 
> addition to xlink's would be that popular (especially given 
> that xlink isn't exactly the most successful part of xml)

XLink has a lot
of attributes the designer has to consider (its complicated), 
but none of them really seem to support the "Web" IME.  I'm not
thinking so much about link semantics as I am about practical
simple application of web infrastructure in XML, along the lines
of "what's the simplest thing that could possibly work?".

For example, in scanning http://www.w3.org/TR/2010/REC-xlink11-20100506/#linking-elements
I don't see anything about the media type of the resource which is
linked to, so there's no advertisement to the client what can be
negotiated without actually trying a link.

Also, I suppose you have to declare the xlink namespace in order to
use xlinks.  Something I was trying to avoid by going to the xml:
namespace.

But, you're correct, adding yet one more "standard" might not solve
anything.  Then again, it might catch on.

Cheers,
Peter

Yes I'm aware of xlink.  The reason I'm thinking about going lower in
the layer stack is the re-invention thing.  Not that XLink is not
useful, but for example atom did not use it, and there are probably other
examples.  

Maybe just the fact that the document has to define the namespace is
enough to deter the use of the xlink:href.  xml:lang etc don't suffer from
this.

Linking is not inherent only to presentation, necessarily.  It is vital to changing
application state, however.  As I understand it, mastery of the web was a goal of
XML, so I'm just dreaming a little.

Cheers,
Peter
> -----Original Message-----
> From: Andrew Welch [mailto:andrew.j.welch@gmail.com] 
> Sent: April 13, 2012 08:50
> To: Rushforth, Peter
> Cc: xml-dev@lists.xml.org
> Subject: Re:  xml:href, xml:rel and xml:type
> 
> > So that makes me wonder if
> > XML would benefit from a _single_ simple link standard, 
> inherited by 
> >all XML vocabularies  in the same manner as xml:base,  xml:lang .
> 
> Just checking as you didn't mention it - are you aware of xlink:
> 
> http://www.w3.org/TR/xlink/
> 
> Usually when this question comes up, the answer is that 
> linking is done in a different layer to the xml (the 
> presentation layer).
> 
> 
> --
> Andrew Welch
> http://andrewjwelch.com
> 

Hi there,

I posted this to an 'official' w3c list but didn't get any response.  That could mean
one of several things... ;-).  

I am interested in "XML on the web".  Some say it failed!  I beg to differ.  But, how could
the story improve, I wonder?  

I am interested in RESTful applications, and in thinking about the space, I have come
to think that XML, while wonderful for creating your own domain specific vocabulary,
also suffers from that very strength:  too many re-inventions of the same thing (because
its so easy to reinvent) leads to no standardization/interoperability at all.

One of the really really really important aspects of REST is that 
links, link relations and media types are central concepts.

In Atom, there is the successful atom:link element.  It is so successful, it is used
in other vocabularies via the atom namespace.  So that makes me wonder if 
XML would benefit from a _single_ simple link standard, inherited by all XML vocabularies
in the same manner as xml:base,  xml:lang . 

My question to the XML community is this:

What would be the value and cost of @xml:rel, @xml:href and @xml:type, 
where "xml:" is automagically mapped to the XML namespace [1], 
"rel" is a link relation [2] and "type" is a MIME media type [3] and xml:href is a 
URI.

xml:type would be 'advisory', in that it would not guarantee what the server would serve
at that URL, but could be used to negotiate the response format for that URI.  This
might also necessitate considering a "xml:hreflang".

Is it enough (would we need xml:hreflang, or more)?  Is it too much (security, impact on parsers, XSLT/XQuery/XForms/XOther processors)?  
Is the use of the xml: namespace impossible at this point?  

Thanks for your thoughts or links.

[1] http://www.w3.org/XML/1998/namespace
[2] http://tools.ietf.org/html/rfc5988#section-5.3
[3] http://tools.ietf.org/html/rfc2046

Cheers,
Peter Rushforth

Its early days, but I thought best to throw this into the wild ...
depx is a package manager that I made for selfish personal reasons,
its got a lot of rough edges and may not do what most ppl expect of a
package manager, but open to any suggestions.

What is depx ?

    Its a package manager that uses github as repository to distribute
packages ... its designed as 'dependency management via convention'
versus black magic.

What you can do with depx:

    browse http://depx.org to discover packages

    download depx client to install/remove packages to your applications

    add a package to the repo by forking
https://github.com/xquery/depx ... more information

Please feel free to criticise, comment, and make suggestions here
https://github.com/xquery/depx/issues?sort=created&direction=desc&state=open

Jim Fuller

I agree that is how it has traditionally been considered.

We had to wrestle with this problem in WS-Calendar, in which services are
scheduled and service entry points and XML documents are intertwined with
iCalendar information (RFC5545) in ways compatible with xCal (RFC6321). The
use cases to extend this model using ITIP-based syndication are many and
varied. We came up with an ugly substitution group in which an interval can
contain a payload (application-specific xml derived from an abstract
calendar type), OR an XLINK (if the reference was to somewhere else) OR an
XPATH (so the reference could be to somewhere else in the same message /
document set) OR an XMLANY. The XPATH approach is most desirable when used
as part of messaging-based communications, while the xlink approach makes
more sense for RESTful approaches. That portion of the spec epitomized the
aphorism that standards work is the selection between the odious and the
unpalatable.

IF there is work to codify / clean up /improve XLINKs, THEN this should be
part of the use cases.


"If something is not worth doing, it`s not worth doing well" - Peter Drucker

Toby Considine
TC9, Inc
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  
Email: Toby.Considine@gmail.com
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com



-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] 
Sent: Friday, April 13, 2012 9:59 AM
To: Toby Considine
Cc: xml-dev@lists.xml.org
Subject: RE:  xml:href, xml:rel and xml:type

Hi Toby,

Thanks for your response. I don't think I understand your message.

I'm not talking about addressing within a document but between documents, on
the web, using URIs. 

I don't think XPath is in scope in other words.

Cheers,
Peter



> -----Original Message-----
> From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of 
> Toby Considine
> Sent: April 13, 2012 09:54
> To: 'Andrew Welch'; Rushforth, Peter
> Cc: xml-dev@lists.xml.org
> Subject: RE:  xml:href, xml:rel and xml:type
> 
> If one were to go down this path, relative addressing, as in xpath, 
> would need to be in the mix.
> 
> I find that when I use these constructs, though, I confuse users.
> 
> 
> "If something is not worth doing, it`s not worth doing well" 
> - Peter Drucker
> 
> Toby Considine
> TC9, Inc
> TC Chair: oBIX & WS-Calendar
> TC Editor: EMIX, EnergyInterop
> U.S. National Inst. of Standards and Tech. Smart Grid Architecture 
> Committee
> 
>   
> Email: Toby.Considine@gmail.com
> Phone: (919)619-2104
> http://www.tcnine.com/
> blog: www.NewDaedalus.com
> 
> 

And then there is the issue of declaring special purpose XML lexicons. Just
as I need a mime type for traditional references, and one needs an
application type for, say, the "mailto" type link, there should, of ging
down this path, be a place to create/register additional
application-namespace types on the references.

In my recent work, I have wrestled with classes of calendar/schedule feeds,
and how links to them should be represented. If these are guides to service
end points, there should be some way to distinguish and select between a
list of them. The idea of a "mini-wsdl" for an array of xlinks w/I a larger
xml document, though, threatens to be like a monkfish, i.e. a relatively
small creature able to swallow a large goose. The monkfish is hideous.
After swallowing it has to lie on the bottom for a week or month to digest. 

tc


"If something is not worth doing, it`s not worth doing well" - Peter Drucker

Toby Considine
TC9, Inc
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  
Email: Toby.Considine@gmail.com
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com



-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] 
Sent: Friday, April 13, 2012 9:18 AM
To: David Carlisle
Cc: xml-dev@lists.xml.org
Subject: RE:  xml:href, xml:rel and xml:type

> From: David Carlisle [mailto:davidc@nag.co.uk]
> Subject: Re:  xml:href, xml:rel and xml:type
> 
> On 13/04/2012 13:36, Rushforth, Peter wrote:
> > Hi there,
> >
> > @xml:href
> 
> As far as I understand your suggestion, having built in link semantics 
> was part of the original 3-part plan for XML (along with styling) but 
> that's xlink:href rather than xml:href. I can't see that adding 
> another standardised href attribute in addition to xlink's would be 
> that popular (especially given that xlink isn't exactly the most 
> successful part of xml)

XLink has a lot
of attributes the designer has to consider (its complicated), but none of
them really seem to support the "Web" IME.  I'm not thinking so much about
link semantics as I am about practical simple application of web
infrastructure in XML, along the lines of "what's the simplest thing that
could possibly work?".

For example, in scanning
http://www.w3.org/TR/2010/REC-xlink11-20100506/#linking-elements
I don't see anything about the media type of the resource which is linked
to, so there's no advertisement to the client what can be negotiated without
actually trying a link.

Also, I suppose you have to declare the xlink namespace in order to use
xlinks.  Something I was trying to avoid by going to the xml:
namespace.

But, you're correct, adding yet one more "standard" might not solve
anything.  Then again, it might catch on.

Cheers,
Peter
_______________________________________________________________________

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

If one were to go down this path, relative addressing, as in xpath, would
need to be in the mix.

I find that when I use these constructs, though, I confuse users.


"If something is not worth doing, it`s not worth doing well" - Peter Drucker

Toby Considine
TC9, Inc
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  
Email: Toby.Considine@gmail.com
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com


-----Original Message-----
From: Andrew Welch [mailto:andrew.j.welch@gmail.com] 
Sent: Friday, April 13, 2012 8:50 AM
To: Rushforth, Peter
Cc: xml-dev@lists.xml.org
Subject: Re:  xml:href, xml:rel and xml:type

> So that makes me wonder if
> XML would benefit from a _single_ simple link standard, inherited by 
>all XML vocabularies  in the same manner as xml:base,  xml:lang .

Just checking as you didn't mention it - are you aware of xlink:

http://www.w3.org/TR/xlink/

Usually when this question comes up, the answer is that linking is done in a
different layer to the xml (the presentation layer).


--
Andrew Welch
http://andrewjwelch.com

_______________________________________________________________________

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

Thanks Lech,

That sounds simpler than I thought... OK. It sounds like I can just plug in the XMP elements to the XSD I already have for the target schema without an intermediary schema...?

Great! :) this is actually what I was thinking would be best but wasn't sure if it could be that simple, as a total beginner at XSLT.

One slight complication is that it may be desirable to retain some structural points, like the rdf:Seq and rdf:Alt from the XMP, where this has meaning that needs to be preserved, but I'm guessing this may also be possible with XSLT?

Thanks again,

Michael

-----Original Message-----
From: Lech Rzedzicki [mailto:xchaotic@gmail.com] 
Sent: 11 April 2012 19:11
To: Michael Hopwood
Cc: xml-dev@lists.xml.org
Subject: Re:  XMP to XML translation?

On 10 April 2012 17:46, Michael Hopwood <michael@editeur.org> wrote:
> Hi all,
> I'm looking for a quick and simple method to transform XMP files into 
> well-formed XML, possibly according to an extremely simplified schema (i.e.
> effectively a root node and a list of allowed elements from selected 
> namespaces, all with cardinality 0-n).


Definitely more XSL would work, just identify what info are you after and write XSL templates to match that and discard everything else. For example for image dimensions, the template would be:

<template match="exif:PixelXDimension"> and <template match="exif:PixelYDimension">


Lech

On 10 April 2012 17:46, Michael Hopwood <michael@editeur.org> wrote:
> Hi all,
> I’m looking for a quick and simple method to transform XMP files into
> well-formed XML, possibly according to an extremely simplified schema (i.e.
> effectively a root node and a list of allowed elements from selected
> namespaces, all with cardinality 0-n).


Definitely more XSL would work, just identify what info are you after
and write XSL templates to match that and discard everything else. For
example for image dimensions, the template would be:

<template match="exif:PixelXDimension"> and <template
match="exif:PixelYDimension">


Lech

Is there something here that might help?

   http://www.CraneSoftwrights.com/resources/#XMP

What I found with the flat XMP structure is that 
it was too restrictive for me to include my own 
XML as marked up XML ... I ended up including it 
as escaped text and I wrote a stylesheet to 
translate the escaped text into the embedded XML instance.

In my case it is an embedded UBL document found in the XMP content.

My package includes a Python application for 
extracting the XMP content from the PDF file.

I hope this helps somewhat, though it isn't exactly what you were asking for.

. . . . . . . . Ken

At 2012-04-10 16:46 +0100, Michael Hopwood wrote:
>I’m looking for a quick and simple method to 
>transform XMP files into well-formed XML, 
>possibly according to an extremely simplified 
>schema (i.e. effectively a root node and a list 
>of allowed elements from selected namespaces, all with cardinality 0-n).
>
>The use case here is to import XMP data into an 
>XSLT engine I’m using, but the existing software 
>can’t handle the RDF/XML of the raw XMP.
>
>Since the XMP is relatively flat, I thought 
>there might be a standard or at least well-known 
>way to get this stuff into a very simple XML 
>form, from whence it could be input into my XSLT 
>engine (which auto-detects the “schema” of the 
>input data before creating an XSLT to transform 
>it and future uploads to a new schema).
>
>I’ve identified which namespaces need to be 
>included in my pseudo-schema, I just wondered if 
>there are some existing tools, preferably free, 
>which can do the job? Can this be done with more XSLT…?
>
>Michael Hopwood
>Linked Heritage Project Lead
>EDItEUR
>United House, North  Road
>London N7 9DP
>UK
>
>Tel: +44 20 7503 6418
>Mob: +44 7811 591036
>Skype: michael.hopwood.editeur
><http://www.linkedheritage.org/>http://www.linkedheritage.org/
>http://editeur.org/



--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- May 2012
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/x/
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

On 09/04/12 16:53, Cezar Andrei wrote:
> Hi Dave,
>
> You could try xsd2inst tool from XMLBeans<http://xmlbeans.apache.org/>
> http://xmlbeans.apache.org/ .
> See details<http://xmlbeans.apache.org/docs/2.0.0/guide/tools.html#xsd2inst>at:
> http://xmlbeans.apache.org/docs/2.0.0/guide/tools.html#xsd2inst
>
> It's available in Ubuntu: sudo apt-get install xmlbeans , also integrated
> as an XQuery module in the next version of Zorba<http://www.zorba-xquery.com>
> http://www.zorba-xquery.com .
>
> Cezar Andrei


I'm using a DTD (DITA), not XSD Andrei, but thanks for the link.
A useful reference.


regards DaveP


>
>> *From: *davep<davep@dpawson.co.uk>
>> *Date: *April 2, 2012 12:30:40 AM PDT
>> *To: *xml-dev@lists.xml.org
>> *Subject: ** Generate xml instance from DTD?*
>>
>> http://java.net/downloads/msv/nightly/
>> Ex Sun xmlgen generates test content from a DTD/Schema,
>> but uses Japanese content?
>>
>>  From the help there seems no way to request English content?
>>
>> Anyone know of other such generators please?
>> Input Schema, root element, output, random, valid XML?
>>
>>
>>
>> regards
>>
>> --
>> Dave Pawson
>> XSLT XSL-FO FAQ.
>> http://www.dpawson.co.uk
>>
>> _______________________________________________________________________
>>
>> 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
>>
>>
>>
>



regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Hi Edwin,

Henri Sivonen uses the datatype libraries for his (X)HTML5 validator. 
This may be an interesting example for you, see:
http://about.validator.nu/#details
http://hsivonen.iki.fi/html5-datatypes/

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

On 4/5/12 12:25 PM, Edwin Dankert wrote:
> Hello George,
>
>> You should look also into Relax NG datatype libraries - basically you can
>> define a type for your expressions and write an implementation for that
>> datatype for your Relax NG processor, Jing for example, then you should be
>> able to use that from a Relax NG schema.
>
> Thank you very much for this. This would have been the solution I
> wanted to implement initially however after some looking at the code
> and documentation for the different validation languages there didn't
> seem to be a clear way to implement this, which lead me to conclude
> that this might not generally be regarded as the preferred way to
> handle this type of functionality and prompted my question.
>
> However if you say that this is actually possible and a valid way to
> handle this issue and I am well aware of your experience in this area,
> I will definitely look at this again but now in more depth using the
> pointers you provided.
>
> Thanks again,
> Edwin
>
> On 4 April 2012 19:56, George Cristian Bina<george@oxygenxml.com>  wrote:
>> Hi Edwin,
>>
>> You should look also into Relax NG datatype libraries - basically you can
>> define a type for your expressions and write an implementation for that
>> datatype for your Relax NG processor, Jing for example, then you should be
>> able to use that from a Relax NG schema.
>>
>> Best Regards,
>> George
>> --
>> George Cristian Bina
>> <oXygen/>  XML Editor, Schema Editor and XSLT Editor/Debugger
>> http://www.oxygenxml.com
>>
>>
>> On 3/30/12 3:35 PM, Edwin Dankert wrote:
>>>
>>> Hello,
>>>
>>> I hope you can guide me in the best way to proceed with this validation
>>> issue.
>>>
>>> I have a XML structure with most of the nodes representing simple
>>> data, like names, references and numeric values.
>>>
>>> <person>
>>>    <name>John<name>
>>>    <salary>1000<salary>
>>> </person>
>>>
>>> However some of the numeric nodes can not only represent the data as
>>> simple numeric values, they can also be specified as an expression and
>>> point to other items in the document.
>>>
>>> <person xmlns="x">
>>>    <name>John<name>
>>>    <salary>100000/$no-of-employees}<salary>
>>> </person>
>>>
>>> The expression language is quite complex and cannot be represented by
>>> a regular-expression. The syntax is however specified using EBNF and
>>> only the syntax needs to be validated.
>>>
>>> A XML Schema for this exists:
>>>
>>> <schema>
>>>    <element name="person">
>>>      <sequence>
>>>        <element name="name" type="Name">
>>>        <element name="salary" type="string">
>>>      </sequence>
>>>    </element>
>>> <schema>
>>>
>>> The goal is to have a standalone tool which can validate using the
>>> more simple constraints specified by the schema and also validate the
>>> values which contain the expression language.
>>>
>>> My preferred solution would involve validating the expression value
>>> syntax directly from the EBNF using standard XML technologies but
>>> don't believe this is currently an option.
>>>
>>> My questions now is: what would be the best way to validate these
>>> values in your opinion or how was this solved in any of your previous
>>> projects? (Note: The validator tool-set already includes Java, NVDL,
>>> XSLT 2.0, XML Schema 1.0.)
>>>
>>> Any suggestions are very welcome.
>>>
>>> Thanks in advance,
>>> Edwin
>>>
>>> _______________________________________________________________________
>>>
>>> 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
>>>
>>
>

Hi Dave,

oXygen includes an XML Schema instance generator tool, see "Tools -> 
Generate sample XML files".
You can convert the DTD to XML Schema first then use that to generate 
instance documents.

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

On 4/2/12 10:30 AM, davep wrote:
> http://java.net/downloads/msv/nightly/
> Ex Sun xmlgen generates test content from a DTD/Schema,
> but uses Japanese content?
>
>  From the help there seems no way to request English content?
>
> Anyone know of other such generators please?
> Input Schema, root element, output, random, valid XML?
>
>
>
> regards
>

On 06/04/12 08:14, XMLBlueprint Team wrote:
> Dave,
>
> Generating an XML instance from a DTD is supported in XMLBlueprint XML
> Editor: open your DTD and select Schema>  Generate Sample XML from DTD.
>
> - Gerben Abbink
>    XMLBlueprint.com

Thanks Gerben. Does it output optional as well as required 
elements/attributes?

I want to check a set of stylesheets (PDF and HTML) so
I want maximum coverage?


regards DaveP


>
>
> On Mon, Apr 2, 2012 at 9:30 AM, davep<davep@dpawson.co.uk>  wrote:
>
>> http://java.net/downloads/msv/**nightly/<http://java.net/downloads/msv/nightly/>
>> Ex Sun xmlgen generates test content from a DTD/Schema,
>> but uses Japanese content?
>>
>>  From the help there seems no way to request English content?
>>
>> Anyone know of other such generators please?
>> Input Schema, root element, output, random, valid XML?
>>
>>
>>
>> regards
>>
>> --
>> Dave Pawson
>> XSLT XSL-FO FAQ.
>> http://www.dpawson.co.uk
>>
>> ______________________________**______________________________**
>> ___________
>>
>> 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/<http://www.oasis-open.org/mlmanage/>
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.**org<xml-dev-unsubscribe@lists.xml.org>
>> subscribe: xml-dev-subscribe@lists.xml.**org<xml-dev-subscribe@lists.xml.org>
>> List archive: http://lists.xml.org/archives/**xml-dev/<http://lists.xml.org/archives/xml-dev/>
>> List Guidelines: http://www.oasis-open.org/**maillists/guidelines.php<http://www.oasis-open.org/maillists/guidelines.php>
>>
>>
>



regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Hello George,

> You should look also into Relax NG datatype libraries - basically you can
> define a type for your expressions and write an implementation for that
> datatype for your Relax NG processor, Jing for example, then you should be
> able to use that from a Relax NG schema.

Thank you very much for this. This would have been the solution I
wanted to implement initially however after some looking at the code
and documentation for the different validation languages there didn't
seem to be a clear way to implement this, which lead me to conclude
that this might not generally be regarded as the preferred way to
handle this type of functionality and prompted my question.

However if you say that this is actually possible and a valid way to
handle this issue and I am well aware of your experience in this area,
I will definitely look at this again but now in more depth using the
pointers you provided.

Thanks again,
Edwin

On 4 April 2012 19:56, George Cristian Bina <george@oxygenxml.com> wrote:
> Hi Edwin,
>
> You should look also into Relax NG datatype libraries - basically you can
> define a type for your expressions and write an implementation for that
> datatype for your Relax NG processor, Jing for example, then you should be
> able to use that from a Relax NG schema.
>
> Best Regards,
> George
> --
> George Cristian Bina
> <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
> http://www.oxygenxml.com
>
>
> On 3/30/12 3:35 PM, Edwin Dankert wrote:
>>
>> Hello,
>>
>> I hope you can guide me in the best way to proceed with this validation
>> issue.
>>
>> I have a XML structure with most of the nodes representing simple
>> data, like names, references and numeric values.
>>
>> <person>
>>   <name>John<name>
>>   <salary>1000<salary>
>> </person>
>>
>> However some of the numeric nodes can not only represent the data as
>> simple numeric values, they can also be specified as an expression and
>> point to other items in the document.
>>
>> <person xmlns="x">
>>   <name>John<name>
>>   <salary>100000/$no-of-employees}<salary>
>> </person>
>>
>> The expression language is quite complex and cannot be represented by
>> a regular-expression. The syntax is however specified using EBNF and
>> only the syntax needs to be validated.
>>
>> A XML Schema for this exists:
>>
>> <schema>
>>   <element name="person">
>>     <sequence>
>>       <element name="name" type="Name">
>>       <element name="salary" type="string">
>>     </sequence>
>>   </element>
>> <schema>
>>
>> The goal is to have a standalone tool which can validate using the
>> more simple constraints specified by the schema and also validate the
>> values which contain the expression language.
>>
>> My preferred solution would involve validating the expression value
>> syntax directly from the EBNF using standard XML technologies but
>> don't believe this is currently an option.
>>
>> My questions now is: what would be the best way to validate these
>> values in your opinion or how was this solved in any of your previous
>> projects? (Note: The validator tool-set already includes Java, NVDL,
>> XSLT 2.0, XML Schema 1.0.)
>>
>> Any suggestions are very welcome.
>>
>> Thanks in advance,
>> Edwin
>>
>> _______________________________________________________________________
>>
>> 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
>>
>

Hi Edwin,

You should look also into Relax NG datatype libraries - basically you 
can define a type for your expressions and write an implementation for 
that datatype for your Relax NG processor, Jing for example, then you 
should be able to use that from a Relax NG schema.

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

On 3/30/12 3:35 PM, Edwin Dankert wrote:
> Hello,
>
> I hope you can guide me in the best way to proceed with this validation issue.
>
> I have a XML structure with most of the nodes representing simple
> data, like names, references and numeric values.
>
> <person>
>    <name>John<name>
>    <salary>1000<salary>
> </person>
>
> However some of the numeric nodes can not only represent the data as
> simple numeric values, they can also be specified as an expression and
> point to other items in the document.
>
> <person xmlns="x">
>    <name>John<name>
>    <salary>100000/$no-of-employees}<salary>
> </person>
>
> The expression language is quite complex and cannot be represented by
> a regular-expression. The syntax is however specified using EBNF and
> only the syntax needs to be validated.
>
> A XML Schema for this exists:
>
> <schema>
>    <element name="person">
>      <sequence>
>        <element name="name" type="Name">
>        <element name="salary" type="string">
>      </sequence>
>    </element>
> <schema>
>
> The goal is to have a standalone tool which can validate using the
> more simple constraints specified by the schema and also validate the
> values which contain the expression language.
>
> My preferred solution would involve validating the expression value
> syntax directly from the EBNF using standard XML technologies but
> don't believe this is currently an option.
>
> My questions now is: what would be the best way to validate these
> values in your opinion or how was this solved in any of your previous
> projects? (Note: The validator tool-set already includes Java, NVDL,
> XSLT 2.0, XML Schema 1.0.)
>
> Any suggestions are very welcome.
>
> Thanks in advance,
> Edwin
>
> _______________________________________________________________________
>
> 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
>

[This announcement will be of interest primarily to those living
in or near Washington, DC, or planning to travel there for the
Joint Conference on Digital Libraries this June, and to those
interested in XForms and/or XQuery training.  If you know others
who meet that description, please forward this announcement to
them.  Thanks!  Others may stop reading now.]

Black Mesa Technologies is pleased to announce two hands-on
introductory courses, one on XForms and one on XQuery, to take place
in June 2012, in Rockville, Maryland (immediately before and after the
ACM/IEEE-CS Joint Conference on Digital Libraries on 10-14 June 2012
at George Washington University in Washington, DC).


INTRODUCTION TO XFORMS FOR XML USERS

   8-9 June 2012, 9:30 - 5:30
   http://www.blackmesatech.com/2012/06/xforms/

   XForms allows you to develop vocabulary- and task-specific editors
   which require less training and provide better task-specific
   support than full XML editors; domain experts can thus examine and
   modify XML encoding mor easily, and routine tasks can be performed
   more quickly and reliably.

   This course introduces XForms as a technology for building
   special-purpose XML editors with focused functionality and
   correspondingly simple user interfaces. XForms is built on the
   model / view / controller idiom, in which the 'model' is a set of
   XML documents, the 'view' is specified using XHTML and XForms
   widgets, and the 'controller' takes the form of declarative links
   between widgets and elements or attributes in the XML documents.


XQUERY FOR DOCUMENTS

   15-16 June 2012, 9:30 - 5:30
   http://www.blackmesatech.com/2012/06/xquery/

   This course introduces XQuery as a flexible language for working
   with natural-language documents (books, prose, verse, drama,
   correspondence, historical documents, articles, legislation, etc.)
   encoded in XML. The focus is on the application of XQuery to
   textual material with complex and variable structure, as opposed to
   the typically simpler, more regular structures of data-oriented
   XML.  The course will cover XPath location paths, atomic values,
   sequences of values, the XDM data model, FLWOR expressions,
   function declarations, regular expressions and string manipulation,
   collections, and the full-text extensions to XQuery.


LOGISTICS

The courses will be held Friday and Saturday, 8-9 June 2012 (XForms)
and Friday and Saturday, 15-16 June 2012 (XQuery), from 9:30 a.m. to
5:30 p.m. at

   Mulberry Technologies, Inc.
   17 West Jefferson St., Suite 207
   Rockville, MD 20850

For other logistical information, see 

    http://www.blackmesatech.com/2011/06/xforms
    http://www.blackmesatech.com/2011/06/xquery

Thanks to Mulberry Technologies for hosting the courses.
 
Other courses that may be relevant to potential attendees (XML Basics,
Schematron, XSLT/XPath Basics, and XSL-FO) are offered in the same
venue on earlier days; see Mulberry Technologies' list of upcoming
classes at

  http://www.mulberrytech.com/services/classes/upcoming.html


REGISTRATION / INFO

To reserve a space, to register, or to ask for more information,
please send email to info@blackmesatech.com or call us at
505/747-4224.


FUTURE ANNOUNCEMENTS

[If you'd like to receive announcements of future courses (etc.) by
email, go to http://lists.blackmesatech.com/blackmesatech-announce-l/
to sign up for the Black Mesa Technologies announcement list.]
 

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Hello David,

> If you wanted to stick to pure xml solutions without using extensions to
> another language you could look at Dimitre Novatchev's LR parser
> generator written in Xpath.

Thank you very much for this, this looks very impressive and I will
definitely give it a try.

Kind regards,
Edwin

On 2 April 2012 10:56, David Carlisle <davidc@nag.co.uk> wrote:
> On 30/03/2012 13:35, Edwin Dankert wrote:
>>
>> The expression language is quite complex and cannot be represented by
>> a regular-expression. The syntax is however specified using EBNF and
>> only the syntax needs to be validated.
>
>
>
> If you wanted to stick to pure xml solutions without using extensions to
> another language you could look at Dimitre Novatchev's LR parser
> generator written in Xpath. I thought he had a blog entry describing it,
> but I didn't see that just now but here's an answer on stack overflow
> giving some description and pointers to the code (which is open source
> on sourceforge)
>
> http://stackoverflow.com/questions/3555211/steps-and-involvement-of-implementing-a-parser-in-net-and-in-this-case-xpath
>
> You could (in theory) use this to write an xpath validating your grammar
> and call that from, say, a schematron rule.
>
> David
>
> --
> google plus: https:/profiles.google.com/d.p.carlisle
>
> ________________________________________________________________________
> The Numerical Algorithms Group Ltd is a company registered in England
> and Wales with company number 1249803. The registered office is:
> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
>
> This e-mail has been scanned for all viruses by Star. The service is
> powered by MessageLabs.
> ________________________________________________________________________

On 30/03/2012 13:35, Edwin Dankert wrote:
> The expression language is quite complex and cannot be represented by
> a regular-expression. The syntax is however specified using EBNF and
> only the syntax needs to be validated.


If you wanted to stick to pure xml solutions without using extensions to
another language you could look at Dimitre Novatchev's LR parser
generator written in Xpath. I thought he had a blog entry describing it,
but I didn't see that just now but here's an answer on stack overflow
giving some description and pointers to the code (which is open source
on sourceforge)

http://stackoverflow.com/questions/3555211/steps-and-involvement-of-implementing-a-parser-in-net-and-in-this-case-xpath

You could (in theory) use this to write an xpath validating your grammar
and call that from, say, a schematron rule.

David

-- 
google plus: https:/profiles.google.com/d.p.carlisle

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________

 >Is there an agreed validation mechanism for open-standards based on 
XML, i.e. do they only release a set of files which allow for validation 
(xml schema, relaxng) or do they release a tool which provides the 
validation when not all constraints can be captured using these languages?

I think practice is highly variable. Some open standards groups consider 
it enough to produce a prose specification, and leave all tooling 
questions entirely to implementors. Some consider it appropriate to 
supplement the prose specifications with things such as XML Schema or 
Relax NG definitions, which they will probably want to ensure are 
portable across multiple processors. Some consider it appropriate to 
provide an online validation service, which can be implemented using any 
tools you like.

Michael Kay
Saxonica

Hello John,

Thank you very much for this.

> Then it is certainly beyond the power of any standard XML tool.  You will
> have to translate the EBNF into an ANTLR or Packrat grammar, or something
> similar depending on what language you are using.  This should be a
> straightforward effort.

I was afraid of that but I was hopeful that some of the people on this
list might have implemented this in a different way, because I believe
in theory the following should be possible:

<rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0">
  <namespace ns="ns">
    <validate schema="test.ebnf" schemaType="application/ebnf"/>
  </namespace>
  ...
</rules>

Kind regards,
Edwin

On 30 March 2012 16:22, John Cowan <cowan@mercury.ccil.org> wrote:
> Edwin Dankert scripsit:
>
>> The expression language is quite complex and cannot be represented by
>> a regular-expression. The syntax is however specified using EBNF and
>> only the syntax needs to be validated.
>
> Then it is certainly beyond the power of any standard XML tool.  You will
> have to translate the EBNF into an ANTLR or Packrat grammar, or something
> similar depending on what language you are using.  This should be a
> straightforward effort.
>
> --
> John Cowan                              cowan@ccil.org
>            http://www.ccil.org/~cowan
> Humpty Dump Dublin squeaks through his norse
>                Humpty Dump Dublin hath a horrible vorse
> But for all his kinks English / And his irismanx brogues
>                Humpty Dump Dublin's grandada of all rogues.  --Cousin James

Hello Michael,

Thank you very much for your reply. I really like this solution (and I
wasn't aware of this feature in Saxon) it would fit in very nicely
with our current set of tools and it would allow to specify this
complex constraint in the same place as the definition of the element
in the XML Schema.

However the validation tool we're trying to put together is supposed
to support an open standard and even though I believe that at least
everybody on this list should buy a copy of your tools if only to
support your enormous contribution to the XML language and community,
I am not sure if I can convince the others in the standardisation
committee.

This actually brings me to a separate but I think related question:

Is there an agreed validation mechanism for open-standards based on
XML, i.e. do they only release a set of files which allow for
validation (xml schema, relaxng) or do they release a tool which
provides the validation when not all constraints can be captured using
these languages? Note: not sure what the distinction is between a
validation tool and a validation schema, when considering NVDL,
Schematron and XSLT, XProc.

What I am trying to find out is if it would be acceptable for the
standard to include in their schemas assertions which are tied to a
specific schema processor and force each member/consumer which wants
to validate their data 'fully' to buy a license of this third party
tool? Note: this assumes that these third-party assertions are ignored
by other tools, so the consumers can still validate their data up-to a
certain level.

Kind regards,
Edwin

On 30 March 2012 17:34, Michael Kay <mike@saxonica.com> wrote:
> If you don't mind a solution that's tied to one schema processor, Saxon
> allows you to use the XSD 1.1 xs:assert feature, and to call out to java
> from the assertions, so you can do arbitrarily complex procedural
> validation.
>
> Michael Kay
> Saxonica
>
>
> On 30/03/2012 13:35, Edwin Dankert wrote:
>>
>> Hello,
>>
>> I hope you can guide me in the best way to proceed with this validation
>> issue.
>>
>> I have a XML structure with most of the nodes representing simple
>> data, like names, references and numeric values.
>>
>> <person>
>>   <name>John<name>
>>   <salary>1000<salary>
>> </person>
>>
>> However some of the numeric nodes can not only represent the data as
>> simple numeric values, they can also be specified as an expression and
>> point to other items in the document.
>>
>> <person xmlns="x">
>>   <name>John<name>
>>   <salary>100000/$no-of-employees}<salary>
>> </person>
>>
>> The expression language is quite complex and cannot be represented by
>> a regular-expression. The syntax is however specified using EBNF and
>> only the syntax needs to be validated.
>>
>> A XML Schema for this exists:
>>
>> <schema>
>>   <element name="person">
>>     <sequence>
>>       <element name="name" type="Name">
>>       <element name="salary" type="string">
>>     </sequence>
>>   </element>
>> <schema>
>>
>> The goal is to have a standalone tool which can validate using the
>> more simple constraints specified by the schema and also validate the
>> values which contain the expression language.
>>
>> My preferred solution would involve validating the expression value
>> syntax directly from the EBNF using standard XML technologies but
>> don't believe this is currently an option.
>>
>> My questions now is: what would be the best way to validate these
>> values in your opinion or how was this solved in any of your previous
>> projects? (Note: The validator tool-set already includes Java, NVDL,
>> XSLT 2.0, XML Schema 1.0.)
>>
>> Any suggestions are very welcome.
>>
>> Thanks in advance,
>> Edwin
>>
>> _______________________________________________________________________
>>
>> 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
>>
>>
>
> _______________________________________________________________________
>
> 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
>

http://java.net/downloads/msv/nightly/
Ex Sun xmlgen generates test content from a DTD/Schema,
but uses Japanese content?

 From the help there seems no way to request English content?

Anyone know of other such generators please?
Input Schema, root element, output, random, valid XML?



regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

If you don't mind a solution that's tied to one schema processor, Saxon 
allows you to use the XSD 1.1 xs:assert feature, and to call out to java 
from the assertions, so you can do arbitrarily complex procedural 
validation.

Michael Kay
Saxonica

On 30/03/2012 13:35, Edwin Dankert wrote:
> Hello,
>
> I hope you can guide me in the best way to proceed with this validation issue.
>
> I have a XML structure with most of the nodes representing simple
> data, like names, references and numeric values.
>
> <person>
>    <name>John<name>
>    <salary>1000<salary>
> </person>
>
> However some of the numeric nodes can not only represent the data as
> simple numeric values, they can also be specified as an expression and
> point to other items in the document.
>
> <person xmlns="x">
>    <name>John<name>
>    <salary>100000/$no-of-employees}<salary>
> </person>
>
> The expression language is quite complex and cannot be represented by
> a regular-expression. The syntax is however specified using EBNF and
> only the syntax needs to be validated.
>
> A XML Schema for this exists:
>
> <schema>
>    <element name="person">
>      <sequence>
>        <element name="name" type="Name">
>        <element name="salary" type="string">
>      </sequence>
>    </element>
> <schema>
>
> The goal is to have a standalone tool which can validate using the
> more simple constraints specified by the schema and also validate the
> values which contain the expression language.
>
> My preferred solution would involve validating the expression value
> syntax directly from the EBNF using standard XML technologies but
> don't believe this is currently an option.
>
> My questions now is: what would be the best way to validate these
> values in your opinion or how was this solved in any of your previous
> projects? (Note: The validator tool-set already includes Java, NVDL,
> XSLT 2.0, XML Schema 1.0.)
>
> Any suggestions are very welcome.
>
> Thanks in advance,
> Edwin
>
> _______________________________________________________________________
>
> 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
>
>

Hello,

I hope you can guide me in the best way to proceed with this validation issue.

I have a XML structure with most of the nodes representing simple
data, like names, references and numeric values.

<person>
  <name>John<name>
  <salary>1000<salary>
</person>

However some of the numeric nodes can not only represent the data as
simple numeric values, they can also be specified as an expression and
point to other items in the document.

<person xmlns="x">
  <name>John<name>
  <salary>100000/$no-of-employees}<salary>
</person>

The expression language is quite complex and cannot be represented by
a regular-expression. The syntax is however specified using EBNF and
only the syntax needs to be validated.

A XML Schema for this exists:

<schema>
  <element name="person">
    <sequence>
      <element name="name" type="Name">
      <element name="salary" type="string">
    </sequence>
  </element>
<schema>

The goal is to have a standalone tool which can validate using the
more simple constraints specified by the schema and also validate the
values which contain the expression language.

My preferred solution would involve validating the expression value
syntax directly from the EBNF using standard XML technologies but
don't believe this is currently an option.

My questions now is: what would be the best way to validate these
values in your opinion or how was this solved in any of your previous
projects? (Note: The validator tool-set already includes Java, NVDL,
XSLT 2.0, XML Schema 1.0.)

Any suggestions are very welcome.

Thanks in advance,
Edwin

Edwin Dankert scripsit:

> The expression language is quite complex and cannot be represented by
> a regular-expression. The syntax is however specified using EBNF and
> only the syntax needs to be validated.

Then it is certainly beyond the power of any standard XML tool.  You will
have to translate the EBNF into an ANTLR or Packrat grammar, or something
similar depending on what language you are using.  This should be a
straightforward effort.

-- 
John Cowan                              cowan@ccil.org
            http://www.ccil.org/~cowan
Humpty Dump Dublin squeaks through his norse
                Humpty Dump Dublin hath a horrible vorse
But for all his kinks English / And his irismanx brogues
                Humpty Dump Dublin's grandada of all rogues.  --Cousin James

At 2012-03-30 10:48 -0400, Toby Considine wrote:
>I have a project wherein I may need to parameterize some Boolean 
>service criteria as they apply to service interactions
>
>Apply this service request to all types that match A, where A may be
>
>
>(A)
>(A)OR(B)
>(A)AND(B)AND(C)
>(A)NOT(B)
>
>Etc.
>
>Is there is some standard dialect or pattern for expressing Boolean 
>selections in XML? I would prefer to do this in some standard way 
>rather than inventing my new, exciting, better, but, sadly, 
>different, means of doing so.

Logical expressions are often written in XPath, a flat non-XML syntax 
with keywords "or" and "and" and the function "not()":

   http://www.w3.org/TR/2007/REC-xpath20-20070123/#id-logical-expressions
   http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#boolean-functions

>Any pointers or discussion of folks favorite way to accomplish this?

One candidate XML syntax would be XQueryX:

   <xqx:andOp>
     <xqx:firstOperand>...</xqx:firstOperand>
     <xqx:secondOperand>...</xqx:secondOperand>
   </xqx:andOp>
   <xqx:orOp>
     <xqx:firstOperand>...</xqx:firstOperand>
     <xqx:secondOperand>...</xqx:secondOperand>
   </xqx:orOp>
   <xqx:functionCallExpr>
     <xqx:functionName>not</xqx:functionName>
     <xqx:arguments>
     ...
     </xqx:arguments>
   </xqx:functionCallExpr>

   http://www.w3.org/TR/2007/REC-xqueryx-20070123/

I hope this helps.

. . . . . . . Ken

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- May 2012
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/x/
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

XMLmind is happy to announce the version 4.6.1 of XMLmind XSL-FO Converter.
    ____________________________________________

XMLmind XSL-FO Converter Personal Edition v4.6.1 can be downloaded from 
http://www.xmlmind.com/foconverter/downloadperso.shtml

Professional Edition users, please upgrade using this form: 
http://www.xmlmind.com/store/download.php

(The above form is usually accessed through 
http://www.xmlmind.com/foconverter/upgrade.html.)
    _____________________________________________

XMLmind XSL-FO Converter v4.6.1 (March 23, 2012):

XMLmind XSL Utility and XMLmind XSL Server:

* now integrate much improved XMLmind DITA Converter
   (ditac) v2.2;

* use new XSLT 2 stylesheets allowing to convert XHTML 1.0,
   1.1 and 5.0 documents to PostScript, PDF, RTF, WordprocessingML,
   Office Open XML (.docx) and OpenOffice (.odt).

   These XSLT 2 stylesheets support a large number of parameters.
   They make an extensive use of xsl:attribute-sets.
   Last but not least, by default, CSS styles specified in
   XHTML style attributes, style and link elements also apply
   to the XSL-FO file generated by these XSLT 2 stylesheets.
    _____________________________________________

More information:
http://www.xmlmind.com/foconverter/changes.html

Dear all,

after some busy weeks, we are glad to announce BaseX 7.2, the EDBT
Release! The latest version offers the following new features:

* support for the new RESTXQ API for building XQuery web services [1]
* improved support for running BaseX as web application [2]
* XQuery: higher order functions added to speed up Top-K queries [3]
* proxy server settings added [4]
* advanced TagSoup options added for importing HTML files [5]
* XQuery: faster traversal of full-text index entries via ft:tokens() [6]
* Command-line: embedded readline and history support via JLine [7]
* XQuery 3.0: annotation added, updated EQName syntax (Q{uri}name)
* opened databases are now pinned OS-wide to reduce write conflicts
* HTML5 serialization of query results
* a printable version of our Wiki documentation

As usual, more infos can be found on our homepage [8]. All your
feedback is welcome. If you will be attending the EDBT Conference next
week, we are looking forward to seeing you there,

Christian,
BaseX Team 2012

[1] http://docs.basex.org/wiki/RESTXQ
[2] http://docs.basex.org/wiki/Web_Application
[3] http://docs.basex.org/wiki/Higher-Order_Functions_Module#hof:top-k-by
[4] http://docs.basex.org/wiki/Options#PROXYHOST
[5] http://docs.basex.org/wiki/Parsers#Options
[6] http://docs.basex.org/wiki/Full-Text_Module#ft:tokens
[7] http://jline.sourceforge.net/
[8] http://basex.org/

Hello Gang,

We are very excited to announce the release of Zorba 2.2, codename "Coeus".
The release announcement is available at
http://www.zorba-xquery.com/html/entry/2012/03/22/Zorba_22 and the
ChangeLog at https://launchpadlibrarian.net/97678336/ChangeLog.

We hope that you will enjoy this release.

May the FLWOR be with you,

William

--
http://www.28msec.com

Thanks to everyone for comments on this thread today.  Most useful food for 
thought.

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
----- Original Message ----- 
From: "David Lee" <dlee@calldei.com>
To: "Pete Cordell" <petexmldev@codalogic.com>; <xml-dev@l...>
Sent: Monday, March 19, 2012 1:45 PM
Subject: RE:  Using XML (or JSON) for inter-thread communication


Nothing multithreaded is ever simplified :)
However point taken.  This is a common use case for example BPEL defines 
endpoints in such a way that can be multithreaded or multi system (but it 
uses that legacy protocol some may have heard of "SOAP").

xmlsh does this in the language itself ... for threads within an xmlsh 
runtime.
Pipelines (a | b ) are run as seperate threads.   Variables can be shared 
across threads.  Starting a new thread ( with "cmd &" ) can share 
(copy-on-write)  all exported variables from the parent environment and can 
return values but outputting to a named port.
Out of process or server communications  can be shared by starting a mini 
HTTP server (httpserver) and then data (xml or otherwise) can be pushed 
through it.

Similarly XProc is designed so it could be multithreaded or multi-server. I 
dont know of any implementations that currently do, but the design was 
intended to allow such a  thing.

And one step up.   the entire internet is designed this way.
Although protocols and implementations vary.


----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org

> -----Original Message-----
> From: Pete Cordell [mailto:petexmldev@codalogic.com]
> Sent: Monday, March 19, 2012 9:34 AM
> To: xml-dev@lists.xml.org
> Subject:  Using XML (or JSON) for inter-thread communication
>
> We all know that increasing processor speed has pretty much run its course
> (for now) and that the way to increased system performance is via using
> multiple cores and threads.  However, parallel programming is difficult.
>
> One of the problems is sharing state across threads and getting race
> conditions etc.
>
> However, systems like web services are effectively multi-process /
> multi-threaded and seem to scale well.  Quite often web services (and
> systems like them) use XML or JSON to communicate between the various
> systems.
>
> Which makes me wonder, can you compress the 'web services' model down to
> the
> level of threads and use XML or JSON for your inter-thread communication?
> Can you define your interfaces using some sort of schema and use REST or
> similar approaches?  Would this help simplify parallel programming, 
> perhaps
> as one of a basket of techniques?
>
> Does anybody have any thoughts on this?
>
> Thanks,
>
> Pete Cordell
> Codalogic Ltd
> Interface XML to C++ the easy way using C++ XML
> data binding to convert XSD schemas to C++ classes.
> Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
> for more info
>
>
> ___________________________________________________________________
> ____
>
> 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
>



_______________________________________________________________________

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

> I assume that under some circumstances it's possible to generate a 
> number of fragments of an output document in parallel and then merge 
> the fragments at the end of the operation.  If so, is XSLT 
> functionalism sufficient to do that automatically, or would some 
> external programmer input be required to implement that?
>
>
Initially we're taking a cautious approach: using multithreading 
automatically where we're pretty confident it will usually give a 
benefit (xsl:result-document, fn:collection()) and allowing it to be 
invoked manually in cases where we think it's likely to incur more cost 
than benefit in a significant number of cases (xsl:for-each, 
xsl:apply-templates). Hopefully the decision-making will become more 
sophisticated as we gain experience and gather user feedback.

Michael Kay
Saxonica

We have use case where we need to see the results of documents processed 
earlier in our pipeline, but in a parallel processing environment they 
may not have finished writing yet.  In a single xslt we are mostly 
protected from this since the results of doc() and other external 
sources of input are required to be immutable, right?  But we supply our 
own functions that query external data sources and they (deliberately) 
break this contract.  And of course if you run multiple xslts in series, 
the results from the first one may show up in the second.  In cases like 
this you need to be careful about synchronizing, and it becomes 
important to introduce a barrier that waits for outstanding writes to 
complete.

I wonder if this sort of issue is being addressed in any way in the 
threading work you're doing in xslt?

-Mike

On 03/19/2012 01:43 PM, Michael Kay wrote:
>
>> I assume that under some circumstances it's possible to generate a 
>> number of fragments of an output document in parallel and then merge 
>> the fragments at the end of the operation.  If so, is XSLT 
>> functionalism sufficient to do that automatically, or would some 
>> external programmer input be required to implement that?
>>
>>
> Initially we're taking a cautious approach: using multithreading 
> automatically where we're pretty confident it will usually give a 
> benefit (xsl:result-document, fn:collection()) and allowing it to be 
> invoked manually in cases where we think it's likely to incur more 
> cost than benefit in a significant number of cases (xsl:for-each, 
> xsl:apply-templates). Hopefully the decision-making will become more 
> sophisticated as we gain experience and gather user feedback.
>
> Michael Kay
> Saxonica
>
> _______________________________________________________________________
>
> 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
>

Original Message From: "Michael Kay"
> On 19/03/2012 14:44, Andrew Welch wrote:
>> On 19 March 2012 14:36, John Cowan  wrote:
>>> Andrew Welch scripsit:
>>>
>>>> As far as I know, as we all move towards functional programming we
>>>> won't have to worry too much about it as it gets taken care of for us.
>>> Good luck with that.
>> Is that not the case?
>>
> Things get better, but the problem shifts.
>
> For example, the next Saxon release will automatically do multi-threading 
> for xsl:result-document (each output document is produced in parallel with 
> the others).

I assume that under some circumstances it's possible to generate a number of 
fragments of an output document in parallel and then merge the fragments at 
the end of the operation.  If so, is XSLT functionalism sufficient to do 
that automatically, or would some external programmer input be required to 
implement that?

Thanks,

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info

On 19 March 2012 14:34, Pete Cordell <petexmldev@codalogic.com> wrote:
..
> One of the problems is sharing state across threads and getting race
> conditions etc.
>
> However, systems like web services are effectively multi-process /
> multi-threaded and seem to scale well.  Quite often web services (and
> systems like them) use XML or JSON to communicate between the various
> systems.
...
> Does anybody have any thoughts on this?
>

Since a few years already, the web apps designed to scale to million
of users seems to use stuff like "memcache" to share data.

The format of the data shared is normally the native of the language,
probably often serialization of objects.  The data don't have to live
longer than the execution of the program, so is ok ( Is not like a
lazy java programmer saving a serialized object to a database).




-- 
--
ℱin del ℳensaje.

On 19/03/2012 14:44, Andrew Welch wrote:
> On 19 March 2012 14:36, John Cowan<cowan@mercury.ccil.org>  wrote:
>> Andrew Welch scripsit:
>>
>>> As far as I know, as we all move towards functional programming we
>>> won't have to worry too much about it as it gets taken care of for us.
>> Good luck with that.
> Is that not the case?
>
Things get better, but the problem shifts.

For example, the next Saxon release will automatically do 
multi-threading for xsl:result-document (each output document is 
produced in parallel with the others). But I had a test case the other 
day where doing everything at the same time blew the heap, so I had to 
suppress the multi-threading in order to conserve memory. Automating the 
resource trade-offs is the next level, but with diminishing returns I 
don't know if it will ever happen. So users still need to know what's 
going on and turn the dials occasionally.

Michael Kay
Saxonica

On 19 March 2012 14:36, John Cowan <cowan@mercury.ccil.org> wrote:
> Andrew Welch scripsit:
>
>> As far as I know, as we all move towards functional programming we
>> won't have to worry too much about it as it gets taken care of for us.
>
> Good luck with that.

Is that not the case?


>> On this topic (sort of), this is an interesting article I read the
>> other day where they took a different approach:
>> http://martinfowler.com/articles/lmax.html
>
> This is a straightforward three-stage pipeline, where the input and
> output stages have state and the processing stage doesn't.

Ah ok... shame you didn't make it first, you could've made a fortune :)


-- 
Andrew Welch
http://andrewjwelch.com

Original Message From: "John Cowan"

> All that parsing and unparsing would be expensive:

That was certainly one of my concerns, does it scale (unscale?!) to the 
tiny?  If the cost of serialization is small compared to the number of cores 
you can throw at a problem then it might cost in.  These days that's 
probably an accessment you have to make on a daily basis!

> you might as well deal
> in binary immutable objects instead.  But otherwise the idea is good and
> has been in use for decades (Unix pipelines being the best-known example).
> The key is to share nothing except immutable objects.

I was thinking the act of serialization could be used to enforce the 
immutability aspects and reduce the changes of unintentionally getting 
access to 'foreign' mutating state.

> See Flow-Based Programming, a framework based on passing around immutable
> packets between components (there are Java, C#, and C++ versions) at
> http://www.jpaulmorrison.com/fbp/ .

Will do, Thanks.

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info

On 19 March 2012 13:34, Pete Cordell <petexmldev@codalogic.com> wrote:
> We all know that increasing processor speed has pretty much run its course
> (for now) and that the way to increased system performance is via using
> multiple cores and threads.  However, parallel programming is difficult.

As far as I know, as we all move towards functional programming we
won't have to worry too much about it as it gets taken care of for us.
 Also, in Android and Java itself there are really good apis that
shield us from the hard stuff, there's no need to work with threads
directly.  I haven't come across an equivalent in Objective-C...

On this topic (sort of), this is an interesting article I read the
other day where they took a different approach:
http://martinfowler.com/articles/lmax.html

"In fact they ended up by doing all the business logic for their
platform: all trades, from all customers, in all markets - on a single
thread. A thread that will process 6 million orders per second using
commodity hardware."





-- 
Andrew Welch
http://andrewjwelch.com

Nothing multithreaded is ever simplified :)
However point taken.  This is a common use case for example BPEL defines endpoints in such a way that can be multithreaded or multi system (but it uses that legacy protocol some may have heard of "SOAP").

xmlsh does this in the language itself ... for threads within an xmlsh runtime.
Pipelines (a | b ) are run as seperate threads.   Variables can be shared across threads.  Starting a new thread ( with "cmd &" ) can share (copy-on-write)  all exported variables from the parent environment and can return values but outputting to a named port.
Out of process or server communications  can be shared by starting a mini HTTP server (httpserver) and then data (xml or otherwise) can be pushed through it.

Similarly XProc is designed so it could be multithreaded or multi-server. I dont know of any implementations that currently do, but the design was intended to allow such a  thing.

And one step up.   the entire internet is designed this way. 
Although protocols and implementations vary.


----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org

> -----Original Message-----
> From: Pete Cordell [mailto:petexmldev@codalogic.com]
> Sent: Monday, March 19, 2012 9:34 AM
> To: xml-dev@lists.xml.org
> Subject:  Using XML (or JSON) for inter-thread communication
> 
> We all know that increasing processor speed has pretty much run its course
> (for now) and that the way to increased system performance is via using
> multiple cores and threads.  However, parallel programming is difficult.
> 
> One of the problems is sharing state across threads and getting race
> conditions etc.
> 
> However, systems like web services are effectively multi-process /
> multi-threaded and seem to scale well.  Quite often web services (and
> systems like them) use XML or JSON to communicate between the various
> systems.
> 
> Which makes me wonder, can you compress the 'web services' model down to
> the
> level of threads and use XML or JSON for your inter-thread communication?
> Can you define your interfaces using some sort of schema and use REST or
> similar approaches?  Would this help simplify parallel programming, perhaps
> as one of a basket of techniques?
> 
> Does anybody have any thoughts on this?
> 
> Thanks,
> 
> Pete Cordell
> Codalogic Ltd
> Interface XML to C++ the easy way using C++ XML
> data binding to convert XSD schemas to C++ classes.
> Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
> for more info
> 
> 
> ___________________________________________________________________
> ____
> 
> 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
> 

We all know that increasing processor speed has pretty much run its course 
(for now) and that the way to increased system performance is via using 
multiple cores and threads.  However, parallel programming is difficult.

One of the problems is sharing state across threads and getting race 
conditions etc.

However, systems like web services are effectively multi-process / 
multi-threaded and seem to scale well.  Quite often web services (and 
systems like them) use XML or JSON to communicate between the various 
systems.

Which makes me wonder, can you compress the 'web services' model down to the 
level of threads and use XML or JSON for your inter-thread communication? 
Can you define your interfaces using some sort of schema and use REST or 
similar approaches?  Would this help simplify parallel programming, perhaps 
as one of a basket of techniques?

Does anybody have any thoughts on this?

Thanks,

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info

In an attempt to redeem myself...

Following on from Michael Kay's comments, when using XSD1.0, the only real 
way to do it is declare your restricted schema to have the same target 
namespace as the Base schema.

I think one way to get around this is to define a 'wrapper' schema and then
xs:include your Base and Restricted namespace within it, e.g.:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.example.org/Base"
targetNamespace="http://www.example.org/Base"
elementFormDefault="qualified">

    <xs:include schemaLocation="Base.xsd"/>
    <xs:include schemaLocation="Restricted.xsd"/>
</xs:schema>

then both have:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.example.org/Base"
targetNamespace="http://www.example.org/Base"
elementFormDefault="qualified">

Alternatively you could make E1 and E2 as global elements in the Base
namespace, but leave the rest in the Restricted namespace and do:

                <xs:restriction base="base:AType">
                                <xs:sequence>
                                                <xs:element ref="base:E1"/>
                                                <xs:element ref="base:E2"/>
                                </xs:sequence>
                </xs:restriction>

HTH,

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
----- Original Message ----- 
From: "Toby Considine" <Toby.Considine@gmail.com>
To: <xml-dev@lists.xml.org>
Sent: Friday, March 16, 2012 6:01 PM
Subject: RE:  Unqualified forms and Inheritance by Restriction


This seems to argue that the tools that "accept" what I am doing now, do so
in error. Which I had an uneasy feeling they did.



>>Because the element declaration isn't global, the only way you can replace
it with a different element declaration of the same name is by putting that
declaration in a schema >>document whose target namespace is {Base}.



How would I do this? I tried several variants on



                <xs:restriction base="base:AType">

                                <xs:sequence>

                                                <xs:element name="base:E1"
type="xs:string" fixed="foo"/>

                                                <xs:element name="base:E2">


<xs:simpleType>


<xs:restriction base="xs:token">


<xs:enumeration value="fie"/>


<xs:enumeration value="foe"/>


</xs:restriction>


</xs:simpleType>

                                                </xs:element>

                                </xs:sequence>

                </xs:restriction>



And they failed the same, even when I went so far as to make E1 and E2 root
elements in base. At this point I am trying to create valid XML by the
infinite monkey approach.



http://en.wikipedia.org/wiki/Infinite_monkey_theorem



tc

  _____

"If something is not worth doing, it`s not worth doing well" - Peter Drucker

  _____


Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee





Email:  <mailto:Toby.Considine@fac.unc.edu> Toby.Considine@g...
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com





From: Michael Kay [mailto:mike@saxonica.com]
Sent: Friday, March 16, 2012 10:53 AM
To: xml-dev@lists.xml.org
Subject: Re:  Unqualified forms and Inheritance by Restriction



The issue here is that if element {Base}E1 is mandatory in the base type,
it's not good enough to have an element {Restricted}E1 in its place in the
derived type: the elements must have the same name.

Because the element declaration isn't global, the only way you can replace
it with a different element declaration of the same name is by putting that
declaration in a schema document whose target namespace is {Base}.

XSD 1.1 solves this by allowing you to specify targetNamespace as an
attribute on a local element declaration. In 1.0, though, there's no
alternative to putting the restricted type in a schema document for the
{Base} namespace -- even if this means tresspassing on someone else's
namespace.

Michael Kay
Saxonica

On 16/03/2012 13:47, Toby Considine wrote:

I have a family of schemas for energy markets that are derived from a root
abstract schema. In most cases, the derived types extend the abstract types
by adding additional elements. This inheritance by addition is
straight-forward.



For one key abstract type, I use inheritance by restriction. Derived types
must have all the elements of the root type, but they may be restricted to a
few enumerated values. Consider the following, simplified and stripped down:



Root Schema:

<xs:schema xmlns:xs= <http://www.w3.org/2001/XMLSchema>
"http://www.w3.org/2001/XMLSchema" xmlns= <VIPRE Anti-phishing found a known 
bad URL in your email message. It was deleted or quarantined, depending on 
your settings, and replaced with this message. The anti-phishing setting is 
located in File>Settings under the Email Protection tab.>
"VIPRE Anti-phishing found a known bad URL in your email message. It was 
deleted or quarantined, depending on your settings, and replaced with this 
message. The anti-phishing setting is located in File>Settings under the 
Email Protection tab." targetNamespace= <VIPRE Anti-phishing found a known 
bad URL in your email message. It was deleted or quarantined, depending on 
your settings, and replaced with this message. The anti-phishing setting is 
located in File>Settings under the Email Protection tab.>
"VIPRE Anti-phishing found a known bad URL in your email message. It was 
deleted or quarantined, depending on your settings, and replaced with this 
message. The anti-phishing setting is located in File>Settings under the 
Email Protection tab." elementFormDefault="qualified">

<xs:element name="A" type="AType"/>

<xs:complexType name="AType" abstract="true">

                <xs:sequence>

                                <xs:element name="E1" type="xs:string"/>

                                <xs:element name="E2" type="xs:string" />

                </xs:sequence>

</xs:complexType>



Derivative schema

<xs:schema xmlns:xs= <http://www.w3.org/2001/XMLSchema>
"http://www.w3.org/2001/XMLSchema" xmlns=
<VIPRE Anti-phishing found a known bad URL in your email message. It was 
deleted or quarantined, depending on your settings, and replaced with this 
message. The anti-phishing setting is located in File>Settings under the 
Email Protection tab.> "VIPRE Anti-phishing found a known bad URL in your 
email message. It was deleted or quarantined, depending on your settings, 
and replaced with this message. The anti-phishing setting is located in 
File>Settings under the Email Protection tab."
xmlns:base= <VIPRE Anti-phishing found a known bad URL in your email 
message. It was deleted or quarantined, depending on your settings, and 
replaced with this message. The anti-phishing setting is located in 
File>Settings under the Email Protection tab.> "VIPRE Anti-phishing found a 
known bad URL in your email message. It was deleted or quarantined, 
depending on your settings, and replaced with this message. The 
anti-phishing setting is located in File>Settings under the Email Protection 
tab."
targetNamespace= <VIPRE Anti-phishing found a known bad URL in your email 
message. It was deleted or quarantined, depending on your settings, and 
replaced with this message. The anti-phishing setting is located in 
File>Settings under the Email Protection tab.>
"VIPRE Anti-phishing found a known bad URL in your email message. It was 
deleted or quarantined, depending on your settings, and replaced with this 
message. The anti-phishing setting is located in File>Settings under the 
Email Protection tab." elementFormDefault="qualified">

<xs:import namespace= <VIPRE Anti-phishing found a known bad URL in your 
email message. It was deleted or quarantined, depending on your settings, 
and replaced with this message. The anti-phishing setting is located in 
File>Settings under the Email Protection tab.>
"VIPRE Anti-phishing found a known bad URL in your email message. It was 
deleted or quarantined, depending on your settings, and replaced with this 
message. The anti-phishing setting is located in File>Settings under the 
Email Protection tab." schemaLocation="Base.xsd"/>

<xs:element name="ARestricted" type="ARestrictedType"/>

<xs:complexType name="ARestrictedType" abstract="false">

<xs:complexContent>

                <xs:restriction base="base:AType">

                                <xs:sequence>

                                                <xs:element name="E1"
type="xs:string" fixed="foo"/>

                                                <xs:element name="E2">


<xs:simpleType>


<xs:restriction base="xs:token">


<xs:enumeration value="fie"/>


<xs:enumeration value="foe"/>


</xs:restriction>


</xs:simpleType>

                                                </xs:element>

                                </xs:sequence>

                </xs:restriction>

</xs:complexContent>

</xs:complexType>



The derivative schema is invalid. In particular, when processed, each
element in ARestricted generates the following error:
"rcase-NameAndTypeOK.1: The declarations' {name}s and {target namespace}s
are not the same: restriction element is <xs:element name="itemDescription">
and base element is <xs:element name="itemDescription">."

http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#rcase-NameAndTypeOK



I can avoid the error if I change each of the schemas from
elementFormDefault="qualified" to elementFormDefault="unqualified". The
derived schema now validates using XML Spy and Liquid XML Studio. When I use
the Liquid Technologies code generation tool to create software objects, the
objects generate XML that looks like what I want.



Here's the question:



Should I be looking for some side effect of switching these schemas from
qualified to unqualified? Is there some hidden problem I will come upon if I
require conforming schemas to be unqualified? I generally prefer "qualified"
for the esthetic reason that I like to see explicit type derivations
(prefices) in the schema. I do not have a feel for what else may be
affected.



Thanks



tc



  _____

"You can cut all the flowers but you cannot keep spring from coming."
-Pablo Neruda.

  _____


Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee






Email:  <mailto:Toby.Considine@fac.unc.edu> Toby.Considine@g...
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

Andrew Welch scripsit:

> >> As far as I know, as we all move towards functional programming we
> >> won't have to worry too much about it as it gets taken care of for
> >> us.
> >
> > Good luck with that.
>
> Is that not the case?

Disclaimer:  I'm not a Haskell programmer, so I don't have a deep
understanding of what I'm saying here.

The virtue of pure functional programming languages is that when you get
your code to compile, it's almost certain to work right.  The problems
are twofold: when your program does not compile, it's often not easy to
figure out just why; and when your program has terrible performance, as
it often will if you write it naively, it's not clear what to do to fix
it.  Both of these are symptoms of the same disconnect: what your code
*appears* to be doing is not at all what the graph reduction machine
inside is *actually* doing.

> Ah ok... shame you didn't make it first, you could've made a fortune
> :)

Eh, working for traders is not the way to a restful life.

-- 
Overhead, without any fuss, the stars were going out.
        --Arthur C. Clarke, "The Nine Billion Names of God"
                John Cowan <cowan@ccil.org>

Andrew Welch scripsit:

> As far as I know, as we all move towards functional programming we
> won't have to worry too much about it as it gets taken care of for us.

Good luck with that.

> On this topic (sort of), this is an interesting article I read the
> other day where they took a different approach:
> http://martinfowler.com/articles/lmax.html

This is a straightforward three-stage pipeline, where the input and
output stages have state and the processing stage doesn't.

-- 
Ambassador Trentino: I've said enough. I'm a man of few words.
Rufus T. Firefly: I'm a man of one word: scram!
        --Duck Soup                     John Cowan <cowan@ccil.org>

XMLmind is happy to announce the version 5.2 of XMLmind XML Editor.
     _____________________________________________

XMLmind XML Editor Personal Edition v5.2 can be downloaded from
http://www.xmlmind.com/xmleditor/download.shtml

Professional Edition users, please upgrade using this form:
http://www.xmlmind.com/store/download.php

(The above form is usually accessed through
http://www.xmlmind.com/xmleditor/upgrade.html.)
     _____________________________________________

XMLmind XML Editor v5.2 (March 14, 2012):

Overhauled XHTML support, now including support for XHTML 5:

* Robust, self-contained, W3C XML Schema for XHTML 5 which
    is as faithful to W3C Working Draft 25 May 2011 as a
    W3C XML Schema can be.

* New CSS stylesheets.

    When the "Emulate Web Browser" stylesheet has been selected,
    XXE will dynamically apply to the styled view all the CSS
    styles found in style attributes, style elements and link
    elements pointing to CSS stylesheets.

* New XSLT 2 stylesheets allow to convert XHTML 1.0, 1.1
    and 5.0 documents to PostScript, PDF, RTF, WordprocessingML,
    Office Open XML (.docx) and OpenOffice (.odt).

    By default, the CSS styles specified in XHTML style attributes,
    style and link elements also apply to the XSL-FO file generated
    by these XSLT 2 stylesheets.
     _____________________________________________

More information:
http://www.xmlmind.com/xmleditor/changes.html

Pete Cordell scripsit:

> Which makes me wonder, can you compress the 'web services' model down to 
> the level of threads and use XML or JSON for your inter-thread 
> communication? Can you define your interfaces using some sort of schema 
> and use REST or similar approaches?  Would this help simplify parallel 
> programming, perhaps as one of a basket of techniques?

All that parsing and unparsing would be expensive: you might as well deal
in binary immutable objects instead.  But otherwise the idea is good and
has been in use for decades (Unix pipelines being the best-known example).
The key is to share nothing except immutable objects.

See Flow-Based Programming, a framework based on passing around immutable
packets between components (there are Java, C#, and C++ versions) at
http://www.jpaulmorrison.com/fbp/ .

-- 
John Cowan  cowan@ccil.org  http://ccil.org/~cowan
If I have not seen as far as others, it is because giants were standing
on my shoulders.
        --Hal Abelson

On 16/03/2012 14:49, Mike Sokolov wrote:
> I assume it's a typo, but that document is dated next year

the last published spec was dated last year:

http://www.w3.org/TR/html-polyglot/

presumably someone struggled to add one:-)

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________

Does it help if you have <xs:restriction base="xs:string"/> for E2 in the 
second case?

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
----- Original Message ----- 
From: "Toby Considine" <Toby.Considine@gmail.com>
To: "xml-Dev Listserv" <xml-dev@lists.xml.org>
Sent: Friday, March 16, 2012 1:47 PM
Subject:  Unqualified forms and Inheritance by Restriction


I have a family of schemas for energy markets that are derived from a root
abstract schema. In most cases, the derived types extend the abstract types
by adding additional elements. This inheritance by addition is
straight-forward.



For one key abstract type, I use inheritance by restriction. Derived types
must have all the elements of the root type, but they may be restricted to a
few enumerated values. Consider the following, simplified and stripped down:



Root Schema:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="VIPRE Anti-phishing found a known bad URL in your email message. It 
was deleted or quarantined, depending on your settings, and replaced with 
this message. The anti-phishing setting is located in File>Settings under 
the Email Protection tab."
targetNamespace="VIPRE Anti-phishing found a known bad URL in your email 
message. It was deleted or quarantined, depending on your settings, and 
replaced with this message. The anti-phishing setting is located in 
File>Settings under the Email Protection tab."
elementFormDefault="qualified">

<xs:element name="A" type="AType"/>

<xs:complexType name="AType" abstract="true">

                <xs:sequence>

                                <xs:element name="E1" type="xs:string"/>

                                <xs:element name="E2" type="xs:string" />

                </xs:sequence>

</xs:complexType>



Derivative schema

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="VIPRE Anti-phishing found a known bad URL in your email message. It 
was deleted or quarantined, depending on your settings, and replaced with 
this message. The anti-phishing setting is located in File>Settings under 
the Email Protection tab."
xmlns:base="VIPRE Anti-phishing found a known bad URL in your email message. 
It was deleted or quarantined, depending on your settings, and replaced with 
this message. The anti-phishing setting is located in File>Settings under 
the Email Protection tab."
targetNamespace="VIPRE Anti-phishing found a known bad URL in your email 
message. It was deleted or quarantined, depending on your settings, and 
replaced with this message. The anti-phishing setting is located in 
File>Settings under the Email Protection tab."
elementFormDefault="qualified">

<xs:import namespace="VIPRE Anti-phishing found a known bad URL in your 
email message. It was deleted or quarantined, depending on your settings, 
and replaced with this message. The anti-phishing setting is located in 
File>Settings under the Email Protection tab."
schemaLocation="Base.xsd"/>

<xs:element name="ARestricted" type="ARestrictedType"/>

<xs:complexType name="ARestrictedType" abstract="false">

<xs:complexContent>

                <xs:restriction base="base:AType">

                                <xs:sequence>

                                                <xs:element name="E1"
type="xs:string" fixed="foo"/>

                                                <xs:element name="E2">


<xs:simpleType>


<xs:restriction base="xs:token">


<xs:enumeration value="fie"/>


<xs:enumeration value="foe"/>


</xs:restriction>


</xs:simpleType>

                                                </xs:element>

                                </xs:sequence>

                </xs:restriction>

</xs:complexContent>

</xs:complexType>



The derivative schema is invalid. In particular, when processed, each
element in ARestricted generates the following error:
"rcase-NameAndTypeOK.1: The declarations' {name}s and {target namespace}s
are not the same: restriction element is <xs:element name="itemDescription">
and base element is <xs:element name="itemDescription">."

http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#rcase-NameAndTypeOK



I can avoid the error if I change each of the schemas from
elementFormDefault="qualified" to elementFormDefault="unqualified". The
derived schema now validates using XML Spy and Liquid XML Studio. When I use
the Liquid Technologies code generation tool to create software objects, the
objects generate XML that looks like what I want.



Here's the question:



Should I be looking for some side effect of switching these schemas from
qualified to unqualified? Is there some hidden problem I will come upon if I
require conforming schemas to be unqualified? I generally prefer "qualified"
for the esthetic reason that I like to see explicit type derivations
(prefices) in the schema. I do not have a feel for what else may be
affected.



Thanks



tc



  _____

"You can cut all the flowers but you cannot keep spring from coming."
-Pablo Neruda.

  _____


Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee





Email:  <mailto:Toby.Considine@fac.unc.edu> Toby.Considine@g...
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

On 16/03/2012 13:06, Dan Brickley wrote:
> Hi
>
> I understand from anecdotal reports and my own experiments that it is
> possible to get most (recent?) browsers to sensibly interpret and render
> well formed XML that "looks a lot like" HTML. With much of HTML, this is
> just a matter of matching case and closing</LI>  etc. The treatment of
> HTML's<HR>  and<BR>  as<HR />  and<BR />  is, it seems, workable.
> I'd very much like to hear that these anecdotes are true, and that
> someone somewhere has undertaken a more comprehensive survey of browser
> behaviour. I guess something like this must be going on in the
> HTML-futures area -- if so a URL pointer would be very much appreciated.
>
> Thanks for any references,
>
> Dan
>


There are lots of gotchas and special cases to beware of see

http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________

I assume it's a typo, but that document is dated next year

On 03/16/2012 09:49 AM, David Carlisle wrote:
> On 16/03/2012 13:06, Dan Brickley wrote:
>> Hi
>>
>> I understand from anecdotal reports and my own experiments that it is
>> possible to get most (recent?) browsers to sensibly interpret and render
>> well formed XML that "looks a lot like" HTML. With much of HTML, this is
>> just a matter of matching case and closing</LI>  etc. The treatment of
>> HTML's<HR>  and<BR>  as<HR />  and<BR />  is, it seems, workable.
>> I'd very much like to hear that these anecdotes are true, and that
>> someone somewhere has undertaken a more comprehensive survey of browser
>> behaviour. I guess something like this must be going on in the
>> HTML-futures area -- if so a URL pointer would be very much appreciated.
>>
>> Thanks for any references,
>>
>> Dan
>>
>
>
> There are lots of gotchas and special cases to beware of see
>
> http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html 
>
>
> David
>
> ________________________________________________________________________
> The Numerical Algorithms Group Ltd is a company registered in England
> and Wales with company number 1249803. The registered office is:
> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
>
> This e-mail has been scanned for all viruses by Star. The service is
> powered by MessageLabs. 
> ________________________________________________________________________
>
> _______________________________________________________________________
>
> 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
>

Simon touches on one of several divides, and they come down to "what is the
purpose of this schema"

I have used XSD an inheritance to define information models. Information
models benefit from abstract types and derivation because extensibility may
be the primary concern.

In a particular application, I may wish to invalidate a message that conveys
information that I do not understand, i.e., I may need to reject a validly
derived but incomprehensible message. This may because the application has a
restricted purpose. My smart refrigerator-based Bar-coded food inventory can
legitimately reject power tools, even if they have valid bar codes. This may
because of a restricted profile for a restricted market. It may be a version
issue, as my v1 system does not understand the options of your v2 message.

WS-I (Interoperability) addresses this be explicitly disallowing the type of
optionality that comes with substitution groups. This does not mean that
substitution groups are bad, it means that they have their place and you
must know if you  are in that place. It is routine to take a information
defined with a substitution group and create a derived schema with a CHOICE
of the derived types that fit a particular WS-I profile.

I have not seen a lot of conversation about this--but that may be my
ignorance of the right readings. I tend toward language such as the
Information Schema and the Application Schema, and the WS-I Profile.

The pleasure of the XML Schema is that it can be used for many things.
The challenge of the XML Schema is that many parts of it should not be used
for many purposes.
The tragedy of the XML Schema is that many practitioners, particularly
tool-based practitioners, do not distinguish between the purposes, and use a
schema built for one purpose for another. 

The same can be said, IMO, for RNG

So: is there a common language describing the purpose of a schema? Is that
language associated with rules for how one should build the schema within
that purpose? Even more to the point is there tooling for, say, validating
an application schema against an information model schema?

tc

"If something is not worth doing, it`s not worth doing well" - Peter Drucker

Toby Considine
TC9, Inc
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  
Email: Toby.Considine@gmail.com
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com


-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com] 
Sent: Friday, March 16, 2012 9:25 AM
To: xml-dev@lists.xml.org
Subject: Re:  RNG vs. XSD : is the use of abstract types and
polymorphism a good or bad thing for schemas for XML?

On 3/14/12 9:03 PM, Rick Jelliffe wrote:
> I like what Norm wrote.I'd add a couple of things.

As do I, though my things are a little different.

 From my perspective, W3C XML Schema was a trainwreck because its foundation
structures came from the languages people wanted to use to process XML with,
not from much precedent in markup itself.  Classical inheritance was the way
of Java and C++ and many others, and was apparently a siren call few could
resist.

Thanks,
--
Simon St.Laurent
http://simonstl.com/

On 3/14/12 9:03 PM, Rick Jelliffe wrote:
> I like what Norm wrote.I'd add a couple of things.

As do I, though my things are a little different.

 From my perspective, W3C XML Schema was a trainwreck because its 
foundation structures came from the languages people wanted to use to 
process XML with, not from much precedent in markup itself.  Classical 
inheritance was the way of Java and C++ and many others, and was 
apparently a siren call few could resist.

(At the time I was doing my XML programming in Java, a choice I've since 
concluded was akin to building a garden with a cement mixer.)

XSLT 1.0 may provide a bit of contrast.  I still think leaping from the 
annotation model of CSS to the transformation model of XSLT was drastic 
overkill for the at least theoretical application of SGML on the Web. 
However, unlike W3C XML Schema, XSLT itself was built on the very 
different, and I now think saner foundations of functional programming 
languages.

Yes, it killed OOP and procedural programmers that variables weren't 
variable.  People who hoped XSLT would convert objects to and from XML 
were disappointed to find that it was really about transformations of 
XML to XML.  Those limits, however, are massive strengths when you need 
XSLT to do the kinds of transformations it was built to do.

It's not really a surprise to me that RELAX NG and XSLT 1.0 have a 
common founder in James Clark, who reliably looked beyond the "why can't 
we make it all look like Java" demands of the day.

I can imagine inheritance working well in a schema language.  It might 
be sane, for instance, to create a data type language using prototypal 
inheritance - what JavaScript is good at - rather than locking itself 
into the hierarchies of classical inheritance.  Alas, I haven't had time 
to play with that.

Maybe that's for the best, though.

Thanks,
-- 
Simon St.Laurent
http://simonstl.com/

Hi

I understand from anecdotal reports and my own experiments that it is
possible to get most (recent?) browsers to sensibly interpret and render
well formed XML that "looks a lot like" HTML. With much of HTML, this is
just a matter of matching case and closing </LI> etc. The treatment of
HTML's <HR> and <BR> as <HR /> and <BR /> is, it seems, workable.
I'd very much like to hear that these anecdotes are true, and that
someone somewhere has undertaken a more comprehensive survey of browser
behaviour. I guess something like this must be going on in the
HTML-futures area -- if so a URL pointer would be very much appreciated.

Thanks for any references,

Dan






c.f. http://www.ch.ic.ac.uk/rzepa/talks/pmr11/xml-dev/9810/0134.html

************* Deadline Extended to March 26, 2012 ***************

(Please accept our apologies if you receive multiple copies of this message)

#################################################################
                      IEEE WETICE 2012
    3rd IEEE Track on Collaborative Modeling and Simulation
                        (Comets 2012)

                      in cooperation with
                  AFIS (INCOSE France Chapter)
              MIMOS (Italian Association for M&S)

                      CALL FOR PAPERS

#################################################################

June 25-27, 2012, Toulouse (France)
http://www.sel.uniroma2.it/comets12

#################################################################
# Papers Due: March 26, 2012 **** Extended Deadline ****
# Accepted papers will be published in the conference proceedings
# by the IEEE Computer Society Press and indexed by EI.
#################################################################

Modeling and Simulation (M&S) is increasingly becoming a central
activity in the design of new systems and in the analysis of
existing systems because it enables designers and researchers to
investigate systems behavior through virtual representations. For
this reason, M&S is gaining a primary role in many industrial and
research fields, such as space, critical infrastructures,
manufacturing, emergency management, biomedical systems and
sustainable future. However, as the complexity of the
investigated systems increases and the types of investigations
widens, the cost of M&S activities increases for the more
complex models and for the communications among a wider number and
variety of M&S stakeholders (e.g., sub-domain experts, simulator
users, simulator engineers, and final system users). To address
the increasing costs of M&S activities, collaborative
technologies must be introduced to support these activities by
fostering the sharing and reuse of models, by facilitating the
communications among M&S stakeholders, and more generally by
integrating processes, tools and platforms.

Aside from seeking applications of collaborative technologies to
M&S activities, the track seeks innovative contributions that
deal with the application of M&S practices to the design of
collaborative environments. These environments are continuously
becoming more complex, and therefore their design requires
systematic approaches to meet the required quality of
collaboration. This is important for two reasons: to reduce
rework activities on the actual collaborative environment, and to
maximize the productivity and the quality of the process the
collaborative environment supports. M&S offers the methodologies
and tools for such investigations and therefore it can be used to
improve the quality of collaborative environments.

A non–exhaustive list of topics of interest includes:

* collaborative environments for M&S
* collaborative Systems of Systems M&S
* workflow modelling for collaborative environments and processes
* agent-based M&S
* collaborative distributed simulation
* collaborative component-based M&S
* net-centric M&S
* web-based M&S
* model sharing and reuse
* model building and evaluation
* modeling and simulation of business processes
* modeling for collaboration
* simulation-based performance evaluation of collaborative networks
* model-driven simulation engineering
* domain specific languages for the simulation of collaborative environments
* domain specific languages for collaborative M&S
* databases and repositories for M&S
* distributed virtual environments
* virtual research environment for M&S
* collaborative DEVS M&S

To stimulate creativity, however, the track maintains a wider
scope and invites interested researchers to present contributions
that offer original perspectives on collaboration and M&S.

+++++++++++++++++++++++++++++++++++
On-Line Submissions and Publication
+++++++++++++++++++++++++++++++++++

CoMetS'12 intends to bring together researchers and practitioners
to discuss key issues, approaches, open problems, innovative
applications and trends in the track research area.

This year, we will accept submissions in two forms:

(1) papers
(2) poster and industrial presentations

(1) Papers should contain original contributions not published or
submitted elsewhere. Papers up to six pages (including figures,
tables and references) can be submitted. Papers should follow the
IEEE format, which is single spaced, two columns, 10 pt
Times/Roman font. All submissions should be electronic (in PDF)
and will be peer-reviewed by at least three program committee
members.

Accepted full papers will be included in the proceedings and
published by the IEEE Computer Society Press (IEEE approval pending).
Please note that at least one author for each accepted paper should
register to attend WETICE 2012 (http://www.wetice.org) to have the
paper published in the proceedings.

(2) Posters should describe a practical, on-the-field, experience in
any domain area using collaborative M&S. The poster submission
requires the submission of an abstract for evaluation from the
organizers. Accepted abstract must be followed by the submission of
a poster which will be displayed at conference time.
With the poster submission, a short (15 minutes) slot might be
allocated for oral presentation illustrating the industrial case.
The presentation may also include a live demo, but it should not
include commercial details.

Interested authors and participants may contact the organizers for
expression of interests and content appropriateness at any time.

Papers and posters can be submitted in PDF format at the submission
site (https://www.easychair.org/conferences/?conf=comets2012),
which is supported by the EasyChair conference management system.
Please feel free to contact the track chairs (comets2012@easychair.org)
if you experience problems with the EasyChair Web site.

+++++++++++++++
Important Dates
+++++++++++++++

* Submission Deadline: March 26, 2012 **** Extended deadline ****
* Notification to authors: April 16, 2012
* Camera Ready to IEEE: April 30, 2012
* Conference dates: June 25 - June 27, 2012


++++++++++++++++++++
Organizing Committee
++++++++++++++++++++

* Andrea D'Ambrogio, University of Roma TorVergata, Italy
* Daniele Gianni, European Space Agency, The Netherlands
* Joachim Fuchs, European Space Agency, The Netherlands
* Giuseppe Iazeolla, University of Roma TorVergata, Italy

+++++++++++++++++
Program Committee
+++++++++++++++++

* Santiago Balestrini, Georgia Institute of Technology, USA
* Massimo Bandecchi, European Space Agency, The Netherlands
* Joseph Giampapa, SEI, Carnegie Mellon University, USA
* Alain Kerbrat, CollESys - AFIS, France
* Axel Lehmann, Universitaet der Bundeswehr Muenchen, Germany
* Cristiano Leorato, Rhea, The Netherlands
* Steve McKeever, University of Oxford, UK
* David Nickerson, Auckland Bioengineering Institute, NZ
* Alfred Park, Oak Ridge National Laboratory, USA
* Wolfgang Prinz, Fraunhofer FIT and RWTH Aachen, Germany
* José L. Risco-Martin, Universidad Complutense de Madrid, Spain
* Jean-Francois Santucci, University of Corsica, France
* Gabriel Wainer, Carleton University, Canada
* Quirien Wijnand, European Space Agency, The Netherlands
* Justyna Zander, Harvard University, USA, and Fraunhofer Institute FOKUS,
Germany
* Heming Zhang, Tsinghua University, China

*** Contact Information ***
Daniele Gianni (track co-chair)
Email: danielegmail-comets@yahoo.it


COMETS 2012 - 3rd IEEE Track on Collaborative Modeling and Simulation
- Call for Papers

************* Deadline Extended to March 26, 2012 ***************

(Please accept our apologies if you receive multiple copies of this message)

#################################################################
                      IEEE WETICE 2012
    3rd IEEE Track on Collaborative Modeling and Simulation
                        (Comets 2012)

                      in cooperation with
                  AFIS (INCOSE France Chapter)
              MIMOS (Italian Association for M&S)

                      CALL FOR PAPERS

#################################################################

June 25-27, 2012, Toulouse (France)
http://www.sel.uniroma2.it/comets12

#################################################################
# Papers Due: March 26, 2012 **** Extended Deadline ****
# Accepted papers will be published in the conference proceedings
# by the IEEE Computer Society Press and indexed by EI.
#################################################################

Modeling and Simulation (M&S) is increasingly becoming a central
activity in the design of new systems and in the analysis of
existing systems because it enables designers and researchers to
investigate systems behavior through virtual representations. For
this reason, M&S is gaining a primary role in many industrial and
research fields, such as space, critical infrastructures,
manufacturing, emergency management, biomedical systems and
sustainable future. However, as the complexity of the
investigated systems increases and the types of investigations
widens, the cost of M&S activities increases for the more
complex models and for the communications among a wider number and
variety of M&S stakeholders (e.g., sub-domain experts, simulator
users, simulator engineers, and final system users). To address
the increasing costs of M&S activities, collaborative
technologies must be introduced to support these activities by
fostering the sharing and reuse of models, by facilitating the
communications among M&S stakeholders, and more generally by
integrating processes, tools and platforms.

Aside from seeking applications of collaborative technologies to
M&S activities, the track seeks innovative contributions that
deal with the application of M&S practices to the design of
collaborative environments. These environments are continuously
becoming more complex, and therefore their design requires
systematic approaches to meet the required quality of
collaboration. This is important for two reasons: to reduce
rework activities on the actual collaborative environment, and to
maximize the productivity and the quality of the process the
collaborative environment supports. M&S offers the methodologies
and tools for such investigations and therefore it can be used to
improve the quality of collaborative environments.

A non–exhaustive list of topics of interest includes:

* collaborative environments for M&S
* collaborative Systems of Systems M&S
* workflow modelling for collaborative environments and processes
* agent-based M&S
* collaborative distributed simulation
* collaborative component-based M&S
* net-centric M&S
* web-based M&S
* model sharing and reuse
* model building and evaluation
* modeling and simulation of business processes
* modeling for collaboration
* simulation-based performance evaluation of collaborative networks
* model-driven simulation engineering
* domain specific languages for the simulation of collaborative environments
* domain specific languages for collaborative M&S
* databases and repositories for M&S
* distributed virtual environments
* virtual research environment for M&S
* collaborative DEVS M&S

To stimulate creativity, however, the track maintains a wider
scope and invites interested researchers to present contributions
that offer original perspectives on collaboration and M&S.

+++++++++++++++++++++++++++++++++++
On-Line Submissions and Publication
+++++++++++++++++++++++++++++++++++

CoMetS'12 intends to bring together researchers and practitioners
to discuss key issues, approaches, open problems, innovative
applications and trends in the track research area.

This year, we will accept submissions in two forms:

(1) papers
(2) poster and industrial presentations

(1) Papers should contain original contributions not published or
submitted elsewhere. Papers up to six pages (including figures,
tables and references) can be submitted. Papers should follow the
IEEE format, which is single spaced, two columns, 10 pt
Times/Roman font. All submissions should be electronic (in PDF)
and will be peer-reviewed by at least three program committee
members.

Accepted full papers will be included in the proceedings and
published by the IEEE Computer Society Press (IEEE approval pending).
Please note that at least one author for each accepted paper should
register to attend WETICE 2012 (http://www.wetice.org) to have the
paper published in the proceedings.

(2) Posters should describe a practical, on-the-field, experience in
any domain area using collaborative M&S. The poster submission
requires the submission of an abstract for evaluation from the
organizers. Accepted abstract must be followed by the submission of
a poster which will be displayed at conference time.
With the poster submission, a short (15 minutes) slot might be
allocated for oral presentation illustrating the industrial case.
The presentation may also include a live demo, but it should not
include commercial details.

Interested authors and participants may contact the organizers for
expression of interests and content appropriateness at any time.

Papers and posters can be submitted in PDF format at the submission
site (https://www.easychair.org/conferences/?conf=comets2012),
which is supported by the EasyChair conference management system.
Please feel free to contact the track chairs (comets2012@easychair.org)
if you experience problems with the EasyChair Web site.

+++++++++++++++
Important Dates
+++++++++++++++

* Submission Deadline: March 26, 2012 **** Extended deadline ****
* Notification to authors: April 16, 2012
* Camera Ready to IEEE: April 30, 2012
* Conference dates: June 25 - June 27, 2012


++++++++++++++++++++
Organizing Committee
++++++++++++++++++++

* Andrea D'Ambrogio, University of Roma TorVergata, Italy
* Daniele Gianni, European Space Agency, The Netherlands
* Joachim Fuchs, European Space Agency, The Netherlands
* Giuseppe Iazeolla, University of Roma TorVergata, Italy

+++++++++++++++++
Program Committee
+++++++++++++++++

* Santiago Balestrini, Georgia Institute of Technology, USA
* Massimo Bandecchi, European Space Agency, The Netherlands
* Joseph Giampapa, SEI, Carnegie Mellon University, USA
* Alain Kerbrat, CollESys - AFIS, France
* Axel Lehmann, Universitaet der Bundeswehr Muenchen, Germany
* Cristiano Leorato, Rhea, The Netherlands
* Steve McKeever, University of Oxford, UK
* David Nickerson, Auckland Bioengineering Institute, NZ
* Alfred Park, Oak Ridge National Laboratory, USA
* Wolfgang Prinz, Fraunhofer FIT and RWTH Aachen, Germany
* José L. Risco-Martin, Universidad Complutense de Madrid, Spain
* Jean-Francois Santucci, University of Corsica, France
* Gabriel Wainer, Carleton University, Canada
* Quirien Wijnand, European Space Agency, The Netherlands
* Justyna Zander, Harvard University, USA, and Fraunhofer Institute
FOKUS, Germany
* Heming Zhang, Tsinghua University, China

*** Contact Information ***
Daniele Gianni (track co-chair)
Email: danielegmail-comets@yahoo.it

I like what Norm wrote.I'd add a couple of things.

XML came out of a desire to reduce the bloat of SGML; I think
instigators of RELAX NG harboured the same desire for RELAX NG: use a
powerful model with a few constructs, add some nice sugar (RNC), and
re-use external standards (XSD datatypes).   This is essentially a
pragmatic view, along the "wrong is right" lines. But the essential
use of the schema language was for validation.

The instigators of XSD had a difference set of desires: superset of
DTDs, superset of inheritance, superset of datatypes plus support
database keys, conversion to and from object systems, be able to model
families of schemas like XHTML, and allow some kinds of internal model
checking (abstract, complex type inheritance). The intent was a schema
language for all seasons. The essential use of the schema language was
type assignment, as in data binding: documents build from systems
generated from an XSD schema would necessarily be valid.  A big set of
requirements leads to a big technology leads to a big chance that any
particular adoption of the technology beyond simple validation would
(have to) leave bits out, making it a gamble whether your system could
support a schema. (XSD 1.1 improves the bang per buck over XSD 1.0,
but increases the risk of not being supported.)

When I look at them, I can understand both approaches, from the angle
that the more complex a system is, the more that extra layers of
abstraction are required. RELAX NG has five kinds of modularity
(pattterns, external ref, include, define, combine) while XSD has a
few more.  So you would expect that the more complex your system is,
that RELAX NG will run out of steam for modeling power than XSD does.

However, as your system gets even more complex, XSD's modeling runs
out of steam too. For example, XSD brings little to the picture when
trying to reconcile dialects: it has no ability to say "this attribute
in schema A is the same as this element in schema B" for example.

So in order to cope with these you either need to abandon RELAX NG and
XSD or build extra layers on top. (The same goes for Schematron too.)
For example, the XBRL effort build modeling on top of XSD.

And the result? XSD starts with so much complexity, that anything
built on top that provides a superset of XSD's capabilities is liable
to be bloated and require a lot of buck per bang. Again, XBRL is an
example. Contrast that with RELAX NG: starting from the smaller neater
base allows neater layering of modeling features above it.

This is not an abstract issue. In my job I have to look at schema
issues where modeling is necessary, but both RELAX NG and XSD do not
provide any assistance. The difference is that RELAX NG was designed
in the expectation of semi-custom extra layers, while XSD was designed
in the expectation of integration into a vendor's toolchain: once you
buy into the toolchain you are stuck/blessed with whatever modeling
capabilities the vendor provides.

Next, two minor quibbles.

First I'd note that things like XSD's  abstract type feature can be
(easily?) fitted on top of RELAX NG, using a Schematron schema: you
just check that a particular set of pattern names (LHS) are not used
directly in an element declaration (RHS).  (And remember that XSD's
complex type derivation is used for model checking as a layer, not as
a method of reducing the number of declarations.)  And a check that a
RELAX NG grammar is not ambiguous (something like XSD's UPA) can be
added on top as well, (though perhaps not with Schematron with XPath 1
since it is not good for tracing arbitrary chains)-- IIRC there was a
Japanese system that featured this. As well as the distinction between
what two schema languages support directly (and how well), there is a
useful distinction between what can be layered on top of them (and how
well).   Are these better done as a layer or monolithic? Are these
better provided as a standard layer or left to the market to decide?

Secondly, the  type derivation by single inheritance in XSD is not the
only game in town, as far as modeling.  What complex type inheritance
does is say that X is also valid against base type Y and all the chain
of base types (with the wrinkle that for derivation by extension by
suffixation in XSD 1.0, you use  (Y,  *)  as the base type.  This kind
of extra check can be done on the schema, as I mentioned.  But it can
also be done by validating the document separately with both X and Y.
And, indeed, this turns out to be a more powerful approach: for
example, there is a RELAX NG schema for HTML with one schema for
normal parent child validation, and another schema that handles
exclusion exceptions (e.g. that an html:a cannot have another html:a
underneath it at any level.)     In order to do this constraint in
XHTML 1.0 you (unless there is some trick with <xsl:key>or something
obscure) you would have to have duplicate content types and because
the global element declarations were in use you would have to use
local declarations only.   There are some modeling problems that are
better dealt with as parallel problems, or with multiple inheritance
(for which, in effect, the grammar needs to support ambiguity.)

If your problem is coping with long-lived dialects, and mapping
between concepts and dialects, DTDs, XML Schemas and RELAX NG don't
provide any help. (Schematron's abstract patterns or XBRL or OWL are
nearer, I think.)    It think XSD's marketing tends to give the false
promise that it is big enough to scale to large issues,  when it is
big enough to get in the way.  RELAX NG's marketing is much clearer
(indeed, a premise of ISO DSDL): solve the small problems fist and
leaving the complex modeling to other layers.

Finally, what is interesting to me is that for the last several years,
over a variety of very large projects, I am seeing RELAX NG Compact
being used by content analysts because of its terseness, then
converted to XSD as needed.  This avoids some of the dangerous corners
of XSD, but I think the main reason is generational (people who grew
up on DTDs) but also practical (being able to write a content model on
a single line, being able to see all the parts of a type on a single
screen, not scrabbling around diagrams, not needing to change tools or
views, not hanging around for the editing tool to [expletive deleted] in all the
schema and load it).  So notional modeling power is one aspect, but
convenience and usability (given a set of experiences and
expectations) may trump power.


Cheers
Rick Jelliffe

----------------------------------------------------------
XMLmind DITA Converter v2.2 (March 13, 2012)
----------------------------------------------------------
Highlights:

* New extended-toc XSLT stylesheet parameter allows to add
    frontmatter and backmatter topicrefs to the
    Table of Contents.

* More powerful and more flexible specification of page
    headers and footers.

* Many new XSLT stylesheet parameters and attribute-sets
    allowing to customize more easily and more extensively
    the presentation of PDF, RTF, etc, output files.

* Support for Antenna House Formatter.
---------------------------------------------------------

More information in
http://www.xmlmind.com/ditac/changes.html

We plan to integrate XMLmind DITA Converter v2.2 in the following
products:
- XMLmind XSL Utility,
- XMLmind XSL Server,
- XMLmind XML Editor Professional Edition,
very shortly.

---

That kind of separation seems logical, particularly in the context of
maintaining the ontology separately, whilst the XML Schemas are manually
kept in sync with the ontology.

Other contexts however do exist:
Imagine an UML ontology which is making good use of abstract classes and
inheritance. Suitable tools can translate UML and generate the XML library
schema components (similar to OASIS UBL's CBC and CAC library schemas). The
generated library components mirror the UML inheritance and abstract
classes. On the other hand, the actual XML document schemas, which are
composed by cherry picking from the XML library components, are not allowed
to define new abstract types or new inheritances.
Such governed use of inheritance and abstract types is almost invisible when
looking at a document schema (good for users), yet provides benefits in
component library structure and use.
For example, document schemas can include the automatically embedded
documentation containing the plain text definition of the UML class
attribute, some of which happen to be inherited attributes.

Just to add a different perspective. 

Juerg
www.d-m-s.co.nz


> -----Original Message-----
> From: Costello, Roger L. [mailto:costello@mitre.org]
> Sent: Wednesday, 14 March 2012 12:30 a.m.
> To: xml-dev@lists.xml.org
> Subject: RE:  RNG vs. XSD : is the use of abstract types and
> polymorphism a good or bad thing for schemas for XML?
> 
> Hi Folks,
> 
> I have been thinking about the issue of "inheritance" in schema languages
for
> XML.
> 
> Recall that James Clark says (paraphrasing) that it is not the role of a
> schema language to model conceptual or semantic relationships such as
> inheritance. Such relationships are best modeled elsewhere.
> 
> That makes sense to me. Separation of concerns is a good thing. Use a
schema
> language to define a template for syntactic organization. Using my
chocolates
> example, use a schema language to show the organization of boxes
(elements)
> and what chocolates (data) goes into each box.
> 
> Use other technologies for expressing relationships and meaning -- use
> ontologies, data specifications, UML, etc.
> 
> That's a nice, clean separation of concerns. That yields more productivity
and
> better results. (Adam Smith, Wealth of Nations)
> 
> I wonder why XML Schemas ever introduced inheritance machinery (derive-by-
> extension, derive-by-restriction, element substitution) into the language?
> The inheritance machinery muddies things up.  It results in XML Schema
trying
> to be both a language of expressing syntactic template and a poor man's
pseudo
> UMLish relationship ontology language.
> 
> This muddiness has created enormous confusion over the years.
> 
> "XML Schema is just syntax."
> 
> "No, XML Schema is semantics, just look at the meaning in this inheritance
> tree."
> 
> It seems that the prudent path is to avoid all inheritance machinery in
XML
> Schema.
> 
> Don't use derive-by-extension, derive-by-restriction, and element
substitution
> . Use XML Schema just for expressing templates of elements and attributes.
> 
> Use ontologies, data specifications, UML, etc. for expressing
relationships
> and meaning.
> 
> Thoughts?
> 
> /Roger
> 
> _______________________________________________________________________
> 
> 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

Roger,

While there may be something to what you're saying--my experience of XML and XML Schema is much too narrow to say--it does seem to me that you're committing a number of category errors here (as in many of your previous posts on syntax and semantics). Let me try to sketch an alternative vision, using a poor-man's plain-text formalism:

Syntax:

(1) XML is a language ("XML"). (Please take "language" here in its standard sense as used in formal language theory, mutatis mutandis.)
(2) It is also, therefore, an infinite set of languages, { XL1, XL2, XL3, ... XLn ... }, each a subset of XML. Some of these are useful to someone, most aren't (in many cases just because they haven't been thought of, and in many more cases because they're lousy languages; please take "lousy" as an undefined primitive predicate to which a variety of intuitive notions may be attached).
(3) An XML schema language is used to define particular XML-subset languages. It does this by defining a test for well-formed-documenthood in the definiendum ("[language] to be defined").
(4) The objects modeled in an XML schema language are syntactical objects in the XML-subset languages it will be used to define.
(5) There are various ways an XML schema language can describe its objects. A highly inefficient but instructive one, for instance, would be an enumeration of the all the well-formed documents in the definiendum. A more sophisticated approach might employ some notions or notions of type, which is just some sort of pattern, more or less detailed in its description. Yet more sophisticated approaches might classify or parameterize those types in various ways. In any event, there is a large body of literature on grammars and what kinds of languages they can model. (See "Chomsky hierarchy" in any formal grammar textbook or reference.)

Semantics:

(A) The semantics of a language can be usefully defined as the set of mappings of "meanings" (we'll leave that deliberately vague) that are mapped onto the language's constructs by users of the language.
(B) Any language that employs words or other meaningful constructs from some other widely used language (such as English) will therefore have a semantics, except in the unusual case in which all its users are unfamiliar with the widely used language.
(C) The syntax of a language limits what kinds of assertions (etc.) about its semantic objects can be expressed in that language.

Some theses about XML that follow:

(T1) The ways a particular XML schema language permits its users to describe its objects (see 4 and 5) have indirectly to do with the semantic ranges of its definienda (by 5 and C).
(T2) Because XML schema languages generally include lots of XML tags from their definienda, and because those tags are generally drawn from widely-used natural languages, a fair smattering of the definiendum's semantics is to be found in the typical XML schema language instance (by B).
(T3) It will be easy for humans, with all their capacity for muddleheadedness as well as connection-making and understanding, to suppose at times when working in an XML schema language that they are saying something about the semantics of the definiendum (by all of the above); in many cases this will be benign (by common observation).
(T4) In contexts in which precision on these points matters, it would be a good thing for the designer of an XML subset language to insure he gives the language sufficient syntactical resources to do its intended semantic job (see C) and to try to avoid loading up the language with unintended, extraneous, or damagingly ambiguous meanings (see B); it would also be a good thing for the writer of any grammar for that language to understand that his job is to define the syntax of the definiendum as clearly and precisely as possible, and to use a grammar language (such as an XML schema language) that will support the project's practical implementation requirements as well as possible. (All of which follows from the general principle that a person who understands what he's doing will frequently do a better job than a person who doesn't.)

Beyond that, I don't think you can go without risk of ideological-purity-unto-irrelevance (see Ron "Consistency" Paul, e.g.)

Norm Birkett

> -----Original Message-----
> From: Costello, Roger L. [mailto:costello@mitre.org]
> Sent: Tuesday, March 13, 2012 7:30 AM
> To: xml-dev@lists.xml.org
> Subject: RE:  RNG vs. XSD : is the use of abstract types and
> polymorphism a good or bad thing for schemas for XML?
> 
> Hi Folks,
> 
> I have been thinking about the issue of "inheritance" in schema
> languages for XML.
> 
> Recall that James Clark says (paraphrasing) that it is not the role of
> a schema language to model conceptual or semantic relationships such as
> inheritance. Such relationships are best modeled elsewhere.
> 
> That makes sense to me. Separation of concerns is a good thing. Use a
> schema language to define a template for syntactic organization. Using
> my chocolates example, use a schema language to show the organization
> of boxes (elements) and what chocolates (data) goes into each box.
> 
> Use other technologies for expressing relationships and meaning -- use
> ontologies, data specifications, UML, etc.
> 
> That's a nice, clean separation of concerns. That yields more
> productivity and better results. (Adam Smith, Wealth of Nations)
> 
> I wonder why XML Schemas ever introduced inheritance machinery (derive-
> by-extension, derive-by-restriction, element substitution) into the
> language?  The inheritance machinery muddies things up.  It results in
> XML Schema trying to be both a language of expressing syntactic
> template and a poor man's pseudo UMLish relationship ontology language.
> 
> This muddiness has created enormous confusion over the years.
> 
> "XML Schema is just syntax."
> 
> "No, XML Schema is semantics, just look at the meaning in this
> inheritance tree."
> 
> It seems that the prudent path is to avoid all inheritance machinery in
> XML Schema.
> 
> Don't use derive-by-extension, derive-by-restriction, and element
> substitution . Use XML Schema just for expressing templates of elements
> and attributes.
> 
> Use ontologies, data specifications, UML, etc. for expressing
> relationships and meaning.
> 
> Thoughts?
> 
> /Roger
> 
> _______________________________________________________________________
> 
> 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

Like it or not, XML Schema has this dual use.
Look at JAXB ... its uses XML Schema to create types and their representations in programming languages.
Look at the type system on XQuery and XSLT.  These are full-fledged data types including inheritance.
Inheritance is very useful in type aware XQuery and XSLT usages as you can do matching (xslt) and typeswitching (xquery)
on types and you dont have to enumerate all the types, only a common base type if that is what you want.  
It may or may not have been a mistake to combine syntax with type modeling in XML Schema,
but its more of a mistake to say now after the fact 'don't use them'.

just my opinion.


----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org

> -----Original Message-----
> From: Costello, Roger L. [mailto:costello@mitre.org]
> Sent: Tuesday, March 13, 2012 7:30 AM
> To: xml-dev@lists.xml.org
> Subject: RE:  RNG vs. XSD : is the use of abstract types and
> polymorphism a good or bad thing for schemas for XML?
> 
> Hi Folks,
> 
> I have been thinking about the issue of "inheritance" in schema languages for
> XML.
> 
> Recall that James Clark says (paraphrasing) that it is not the role of a schema
> language to model conceptual or semantic relationships such as inheritance.
> Such relationships are best modeled elsewhere.
> 
> That makes sense to me. Separation of concerns is a good thing. Use a schema
> language to define a template for syntactic organization. Using my chocolates
> example, use a schema language to show the organization of boxes (elements)
> and what chocolates (data) goes into each box.
> 
> Use other technologies for expressing relationships and meaning -- use
> ontologies, data specifications, UML, etc.
> 
> That's a nice, clean separation of concerns. That yields more productivity and
> better results. (Adam Smith, Wealth of Nations)
> 
> I wonder why XML Schemas ever introduced inheritance machinery (derive-by-
> extension, derive-by-restriction, element substitution) into the language?  The
> inheritance machinery muddies things up.  It results in XML Schema trying to be
> both a language of expressing syntactic template and a poor man's pseudo
> UMLish relationship ontology language.
> 
> This muddiness has created enormous confusion over the years.
> 
> "XML Schema is just syntax."
> 
> "No, XML Schema is semantics, just look at the meaning in this inheritance
> tree."
> 
> It seems that the prudent path is to avoid all inheritance machinery in XML
> Schema.
> 
> Don't use derive-by-extension, derive-by-restriction, and element substitution .
> Use XML Schema just for expressing templates of elements and attributes.
> 
> Use ontologies, data specifications, UML, etc. for expressing relationships and
> meaning.
> 
> Thoughts?
> 
> /Roger
> 
> ___________________________________________________________________
> ____
> 
> 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
> 

Hi Folks,

I have been thinking about the issue of "inheritance" in schema languages for XML.

Recall that James Clark says (paraphrasing) that it is not the role of a schema language to model conceptual or semantic relationships such as inheritance. Such relationships are best modeled elsewhere.

That makes sense to me. Separation of concerns is a good thing. Use a schema language to define a template for syntactic organization. Using my chocolates example, use a schema language to show the organization of boxes (elements) and what chocolates (data) goes into each box. 

Use other technologies for expressing relationships and meaning -- use ontologies, data specifications, UML, etc.

That's a nice, clean separation of concerns. That yields more productivity and better results. (Adam Smith, Wealth of Nations)

I wonder why XML Schemas ever introduced inheritance machinery (derive-by-extension, derive-by-restriction, element substitution) into the language?  The inheritance machinery muddies things up.  It results in XML Schema trying to be both a language of expressing syntactic template and a poor man's pseudo UMLish relationship ontology language. 

This muddiness has created enormous confusion over the years. 

"XML Schema is just syntax."   

"No, XML Schema is semantics, just look at the meaning in this inheritance tree."

It seems that the prudent path is to avoid all inheritance machinery in XML Schema. 

Don't use derive-by-extension, derive-by-restriction, and element substitution . Use XML Schema just for expressing templates of elements and attributes. 

Use ontologies, data specifications, UML, etc. for expressing relationships and meaning.

Thoughts?

/Roger

In my opinion, what is "conceptual" and what is a "Model" depends on the use cases. 
Suppose I want to model a language type hierarchy.  Then "Inheritance" is not just conceptual, its the actual model.
In fact, as far as I can tell, this is exactly what the type system in XQuery and XSLT are ... and as I'm learning, one reason RNG cannot be used to supply the type information for them.
 
That doesnt necessarily mean its 'wrong' ... just that it is not solving the particular problem of modeling types for XQuery and XSLT.


----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org


> -----Original Message-----
> From: Costello, Roger L. [mailto:costello@mitre.org]
> Sent: Monday, March 12, 2012 2:13 PM
> To: xml-dev@lists.xml.org
> Subject: RE:  RNG vs. XSD : is the use of abstract types and
> polymorphism a good or bad thing for schemas for XML?
> 
> James Clark asserts that it is not the role of a schema language to model
> "conceptual" relationships such as inheritance. Such relationships are best
> modeled elsewhere.
> 
> Let us suppose that James is correct.
> 
> Question: Is it best practice to avoid the inheritance machinery provided in XML
> Schema -- derive-by-extension, derive-by-restriction, and element substitution?
> What are the practical benefits of doing so?
> 
> /Roger
> 
> 
> ___________________________________________________________________
> ____
> 
> 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
> 

James Clark asserts that it is not the role of a schema language to model "conceptual" relationships such as inheritance. Such relationships are best modeled elsewhere.

Let us suppose that James is correct.

Question: Is it best practice to avoid the inheritance machinery provided in XML Schema -- derive-by-extension, derive-by-restriction, and element substitution? What are the practical benefits of doing so?

/Roger

Very interesting.  This also more clearly explains why RNG does not provide "type" like XSD does.
It provides validation but not typing.

I don't agree with the premise, however, that representing inheritance (or type) is irrelevant to the conceptual model. 
What if the conceptual model is in fact inheritance as opposed to a mechanism of representing a conceptual model.
It may be irrelevant to some classes of conceptual models ... 

----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org

> -----Original Message-----
> From: Costello, Roger L. [mailto:costello@mitre.org]
> Sent: Monday, March 12, 2012 1:04 PM
> To: xml-dev@lists.xml.org
> Subject: RE:  RNG vs. XSD : is the use of abstract types and
> polymorphism a good or bad thing for schemas for XML?
> 
> John Cowan wrote:
> 
> > See http://www.thaiopensource.com/relaxng/design.html#section:15
> > for James's thinking on inheritance in schema languages.
> 
> Fascinating!
> 
> Here are a few excepts from the article:
> 
>     One of the most significant differences between RELAX NG and
>     W3C XML Schema is that RELAX NG does not have any concept
>     of inheritance.
> 
>     Inheritance has proven to be very useful in modeling languages
>     such as UML. However, I would argue that trying to make an XML
>     schema language also be a modeling language is not a good idea.
>     An XML schema language has to be concerned with syntactic details,
>     such as whether to use elements or attributes, which are irrelevant
>     to the conceptual model.
> 
>     ... there is no need for it to support inheritance; the role of the schema
>     language is purely to describe the XML syntax used to represent the
>     conceptual model.
> 
>     ... the role of the schema language is purely to describe the XML syntax
>     used to represent the conceptual model. RELAX NG has the advantage in
>     this role that it provides more flexibility in the choice of syntax.
> 
> /Roger
> 
> 
> ___________________________________________________________________
> ____
> 
> 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
> 

John Cowan wrote:

> See http://www.thaiopensource.com/relaxng/design.html#section:15 
> for James's thinking on inheritance in schema languages.

Fascinating!

Here are a few excepts from the article:

    One of the most significant differences between RELAX NG and 
    W3C XML Schema is that RELAX NG does not have any concept 
    of inheritance. 

    Inheritance has proven to be very useful in modeling languages 
    such as UML. However, I would argue that trying to make an XML 
    schema language also be a modeling language is not a good idea. 
    An XML schema language has to be concerned with syntactic details, 
    such as whether to use elements or attributes, which are irrelevant 
    to the conceptual model.

    ... there is no need for it to support inheritance; the role of the schema 
    language is purely to describe the XML syntax used to represent the 
    conceptual model.

    ... the role of the schema language is purely to describe the XML syntax 
    used to represent the conceptual model. RELAX NG has the advantage in 
    this role that it provides more flexibility in the choice of syntax.

/Roger

On 12/03/2012 14:37, Costello, Roger L. wrote:
> Hi Folks,
>
> James Clark and MURATA Makoto are the two principles that were
> involved in designing RELAX NG.
>
> I noticed that they did not incorporate into RELAX NG these
> features:
>
> - a reusable collection of elements and attributes that is
> designated "abstract"
>
> -- XML Schema has this. It is a complexType with abstract="true"
>
> - polymorphism (i.e., the ability to replace one thing with another
> provided both things descend from the same type)
>
> -- XML Schema has this. It is element substitution and type
> substitution
>
>
> I wonder why James Clark and MURATA Makoto didn't incorporate
> abstract types and polymorphism into RELAX NG?

relaxng patterns correspond to structural typing, so both of these
things are automatic (or irrelevant depending on your point of view)

In xsd you can have two types that have identical structure but
different names. unless you declare suitable inheritance or substitution
rules they will not be interchangeable. A relaxng pattern in essentially
just a macro for a fragment of a content model, so if they have the same
structure they are always interchangeable.

David



________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________

Hi Folks,

James Clark and MURATA Makoto are the two principles that were involved in designing RELAX NG.

I noticed that they did not incorporate into RELAX NG these features:

- a reusable collection of elements and attributes that is designated "abstract" 

   -- XML Schema has this. It is a complexType with abstract="true"

- polymorphism (i.e., the ability to replace one thing with another provided both things descend from the same type)

   -- XML Schema has this. It is element substitution and type substitution


I wonder why James Clark and MURATA Makoto didn't incorporate abstract types and polymorphism into RELAX NG? 

James Clark and MURATA Makoto are both really, really smart guys. 

I am sure they had good reasons for not incorporating these things.

I can think of two possible reasons:

(1) They determined that abstract types and polymorphism are not appropriate for a schema language for XML.

(2) They determined that incorporating those features would have made RELAX NG too complicated.

If the reason is (1) then I would like to know why abstract types and polymorphism are not appropriate for a schema language for XML? Are there dangers in designing schemas for XML that use abstract types and polymorphism? Does James Clark and MURATA Makoto recommend, when using XML Schemas, avoiding its abstract types and polymorphism?

/Roger

Costello, Roger L. scripsit:

> If the reason is (1) then I would like to know why abstract types and
> polymorphism are not appropriate for a schema language for XML? Are
> there dangers in designing schemas for XML that use abstract types
> and polymorphism? Does James Clark and MURATA Makoto recommend, when
> using XML Schemas, avoiding its abstract types and polymorphism?

See http://www.thaiopensource.com/relaxng/design.html#section:15 for
James's thinking on inheritance in schema languages.

I would add that XML Schema expresses three kinds of constraints:
schema-instance constraints (the schema limits what the instance can
contain), schema-schema constraints (parts of the schema limits what
other parts of the schema can contain), and instance-instance constraints
(parts of the instance limit what other parts of the instance can contain,
as specified by the schema).  Type extension and restriction belong to
the second class of constraints, but RELAX NG expresses only the first
class (except for DTD-compatible ID and IDREF(S), which are a trivial
example of the third class).

-- 
John Cowan  http://ccil.org/~cowan    cowan@ccil.org
There are books that are at once excellent and boring.  Those that at
once leap to the mind are Thoreau's Walden, Emerson's Essays, George
Eliot's Adam Bede, and Landor's Dialogues.  --Somerset Maugham

David Lee scripsit:

> 1) A Standard (or well adopted convention) for Serialized XDM so that
> programs may exchange XDM in addition to XML
> 
> 2) Better support for XDM in XQuery and XSLT to allow the input 'document'
> to be any XDM value, and corresponding support in the implementations to
> portably read such data (see #1)
> 
> 3) Adoption of the JSON Data model into XDM so that XPath/XSLT/XQuery/Schema
> can be directly used on JSON data
> 
> 4) A standard/convention for JSON / XDM conversions  to allow #1 as  both
> input and output.

I think these can be all achieved with an upward-compatible extension to
JSON, adding new syntax to represent the types of XDM 3.0, since that
already has sequences and mappings.  The obvious extension is to allow
an Element Node to be represented using the syntax of an XML element:

	{"foo" = <element/>, "bar" = <simple>element</simple>}

	[<this/>, <that>, <the><other/></the>]

The same story for Comment and PI nodes:

	[<!-- here's a comment node -->, <?here is a PI/>]

Typed literals can be done as in Turtle or SPARQL:

	{"value" = "32767"^^xsd:short}

Attribute and Namespace nodes can be done thus:

	{"this" = @this = "thisval", "that" = @xmlns:foo =
	"http://example"}

Lastly, a Document node might look like a sequence preceded by the word
"document":

	document [<!-- prolog comment -->, <root/>, <!-- epilog -->]

-- 
A mosquito cried out in his pain,               John Cowan
"A chemist has poisoned my brain!"              http://www.ccil.org/~cowan
        The cause of his sorrow                 cowan@ccil.org
        Was para-dichloro-
Diphenyltrichloroethane.                                (aka DDT)

Hi Folks,

I am creating the architectural plan of a building.

At the appropriate time I will make my plan visible for others to see.

Should my plan contain data that indicates whether it is visible?

    visible :: (yes | no)

I am thinking that my architectural plan document should contain "visible" data.

In this message I will attempt to persuade you that my plan should contain "visible" data.

Here's my argument:

Case #1

Let's first consider the case where my plan does not contain "visible" data.

Then there must be some mechanism (perhaps a software program) that, at the appropriate time, makes the plan visible.

That mechanism is in control -- it controls the visibility of my architectural plan.

To put it another way, the mechanism controls the data.

I assert that that is the opposite to what is desired. What is desired is for the data to control the mechanism. Even better, the data is the mechanism.

Case #2

Let's now consider the case where my architectural plan document does contain "visible" data.

At the appropriate time "visible" is changed to the value "yes." Once that happens my architectural plan is visible for others to see.

"Hmm, how did your plan become visible?" you ask.

There are ways to accomplish this using today's technology: there may be a software program that regularly inspects "visible" in my architecture plan document; once the software program detects that "visible" has the value "yes" then the program moves the document into a folder that is viewable by others.

Using today's technology there is a distinct separation between the data and the program: 

    A program processes the data.

I assert that in the (near) future there will be no separation between the data and the program: 

    The data is the program. When the data changes, the world changes.

Thus, once "visible" is changed to "yes" my architectural plan is visible.

This probably sounds like hocus pocus, but there is a more fundamental issue underlying. 

The issue is one of control.

In the first case, where there is no "visible" data, the program is entirely in control. There is no change in visibility of my architectural plan document unless and until the program does something.

In the second case, where there is "visible" data, the architectural plan document is entirely in control. There is no change in visibility of my architectural plan document unless and until the data changes.

That is a huge difference.

------

Okay, that's my argument. 

Have I persuaded you that "visible" should be part of my architectural plan document? If not, what is my argument missing, where has my argument run astray?

/Roger

On Mar 11, 2012 9:39 AM, "Costello, Roger L." <costello@mitre.org> wrote:

>
> Have I persuaded you that "visible" should be part of my architectural plan document? If not, what is my argument missing, where has my argument run astray?
>

No, you are confusing document state with authorization.  You have two
roles for your document: creator and viewer.  You have two states:
draft and published.  Who get's to see what is dependent on their role
and the state of the document.  "Visible" is one small part of the
authorizations attached to a given role. At best it makes some sense
to embed the state of the document in the document (as metadata).  The
matrix of what role has what authorization is probably also dependent
on context the document is being used in at any given moment, so I
doubt there is ever a valid reason to embed the state / role matrix in
the document; there could be many of them...

" understanding how the people and necessary tasks interact, and that's a
different sort of skill than programming."

Actually... no.  Unless one understands the human in the loop problems,
writing a GUI they WILL use is damn near impossible.   Auto-generators are
great.  IronSpeed is a marvel.  But getting the data up in a form they can
recognize without much training is a programming art.  The non-programming
art is selling it.  Very different mindset.

Disclaimer:  I haven't programmed to the
touch-me-squeeze-me-flip-me-make-me-write-bad-checks interfaces for pads and
mobile.   I'd love to read some comparative experiences.

len


-----Original Message-----
From: Liam R E Quin [mailto:liam@w3.org] 
Sent: Thursday, March 08, 2012 9:42 PM
To: Len Bullard
Cc: xml-dev@lists.xml.org
Subject: Re:  Should XML Professionals Be Programmers?

On Thu, 2012-03-08 at 10:27 -0600, Len Bullard wrote:
> It's a general qualifications question:  do you expect an XML
> professional to:

> 1.	Be able to correctly interpret DTD/Schema?
> 2.	Write or modify a DTD/Schema
> 3.	Code and/or test and modify XSLT.
> 4.	Program at least to a level of proficiency to build simple
> productivity tools (for example, basic querying of XML in some form)

Not necessarily.

Someone doing day-to-day text processing will be much more productive if
they can write scripts, use regular expressions, and do not wear overly
restrictive clothing.

If that day-to-day work involves _creating_ schemas, or working with
multiple types of document, familiarity with the validation languages in
use may be a distinct plus, for sure.

"What Every Unix Programmer Should Know" isn't all that far away from
"What Every XML Developer Should Know" in practice, with languages like
XLST, XSD and XQuery taking the place of shell scripts, sed scripts and
awk programs.

The big questions are not only "does she know the details?" but, "does
he work with the bigger picture in mind?"  Introducing XML into a
workflow involves understanding how the people and necessary tasks
interact, and that's a different sort of skill than programming.

Similarly, transcribing and marking up XML documents (medieval Greek
travel diaries, for example) may require understanding of the documents
and they way they use structure and language - their rhetorical nature,
if you will - and again that's not primarily a programming perspective,
although in designing the markup it's necessary to discuss needs with
whoever will be responsible for processing the marked up documents.

There's no single answer.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/


_______________________________________________________________________

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

> OK.  Where's the code?

I doubt the code will be released.  But I don't see why that matters.  If 
you disbelieve the claim that it's possible to build 'fast enough' parsers 
without the code, so be it. But you do not need the code to be able to 
take our concern about balkanization at face value.

        /r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/

In organizations that understand how to process information such that  
creating the XML is efficient and accurate, this can be so.  If an  
organization doesn't have that understanding, then being able to  
program to a level consistent with  the objectives is how one can  
achieve them effectively.

On the other hand, if the supervisor says "I pay you to do XML, not  
program", then it's pretty obvious that they don't understand the  
objectives and effective ways to meet them.  The "tagger" philosophy  
is actively harmful.  It is a mindset we supported to get editors that  
enable correct by construction editing, but I think we were wrong or  
expected too much of these tools and harmed our industry.

len


Quoting Liam R E Quin <liam@w3.org>:

> On Thu, 2012-03-08 at 10:27 -0600, Len Bullard wrote:
>> It's a general qualifications question:  do you expect an XML
>> professional to:
>
>> 1.	Be able to correctly interpret DTD/Schema?
>> 2.	Write or modify a DTD/Schema
>> 3.	Code and/or test and modify XSLT.
>> 4.	Program at least to a level of proficiency to build simple
>> productivity tools (for example, basic querying of XML in some form)
>
> Not necessarily.
>
> Someone doing day-to-day text processing will be much more productive if
> they can write scripts, use regular expressions, and do not wear overly
> restrictive clothing.
>
> If that day-to-day work involves _creating_ schemas, or working with
> multiple types of document, familiarity with the validation languages in
> use may be a distinct plus, for sure.
>
> "What Every Unix Programmer Should Know" isn't all that far away from
> "What Every XML Developer Should Know" in practice, with languages like
> XLST, XSD and XQuery taking the place of shell scripts, sed scripts and
> awk programs.
>
> The big questions are not only "does she know the details?" but, "does
> he work with the bigger picture in mind?"  Introducing XML into a
> workflow involves understanding how the people and necessary tasks
> interact, and that's a different sort of skill than programming.
>
> Similarly, transcribing and marking up XML documents (medieval Greek
> travel diaries, for example) may require understanding of the documents
> and they way they use structure and language - their rhetorical nature,
> if you will - and again that's not primarily a programming perspective,
> although in designing the markup it's necessary to discuss needs with
> whoever will be responsible for processing the marked up documents.
>
> There's no single answer.
>
> Liam
>
> --
> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
> Pictures from old books: http://fromoldbooks.org/
>
>
> _______________________________________________________________________
>
> 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
>
>

Len Bullard wrote:> It's a general qualifications question:

IBM XML Certification
http://www-03.ibm.com/certify/certs/xm_index.shtml

Prometric XML Master Certifications
http://www.prometric.com/XML/default.htm

And of course, from the 2005 archive of xml.com:

"Deconstructing Certification" by Micah Dubinko
http://www.xml.com/pub/a/2005/03/16/deviant.html




Ken North
________________
www.kncomputing.com
@knorth2
kncomputing.tumblr.com

 

On Thu, 2012-03-08 at 10:27 -0600, Len Bullard wrote:
> It's a general qualifications question:  do you expect an XML
> professional to:

> 1.	Be able to correctly interpret DTD/Schema?
> 2.	Write or modify a DTD/Schema
> 3.	Code and/or test and modify XSLT.
> 4.	Program at least to a level of proficiency to build simple
> productivity tools (for example, basic querying of XML in some form)

Not necessarily.

Someone doing day-to-day text processing will be much more productive if
they can write scripts, use regular expressions, and do not wear overly
restrictive clothing.

If that day-to-day work involves _creating_ schemas, or working with
multiple types of document, familiarity with the validation languages in
use may be a distinct plus, for sure.

"What Every Unix Programmer Should Know" isn't all that far away from
"What Every XML Developer Should Know" in practice, with languages like
XLST, XSD and XQuery taking the place of shell scripts, sed scripts and
awk programs.

The big questions are not only "does she know the details?" but, "does
he work with the bigger picture in mind?"  Introducing XML into a
workflow involves understanding how the people and necessary tasks
interact, and that's a different sort of skill than programming.

Similarly, transcribing and marking up XML documents (medieval Greek
travel diaries, for example) may require understanding of the documents
and they way they use structure and language - their rhetorical nature,
if you will - and again that's not primarily a programming perspective,
although in designing the markup it's necessary to discuss needs with
whoever will be responsible for processing the marked up documents.

There's no single answer.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

On Thu, 2012-03-08 at 16:43 +0000, Michael Kay wrote:

> There's no such thing as an XML professional, any more than you can be a 
> screwdriver professional or a fork-lift truck professional.

Actually there _are_ professional fork-lift operators; they go on
courses and get qualifications to operate the machinery.


>  People who 
> define their abilities by the tools they can use proficiently are not 
> professionals, they are technicians; professionals define their 
> capabilities in terms of the problem space, not the solution space.

A profession is a job that requires training and a qualification.

If people are working with XML, let's allow them to sit at the High
Table regardless of whether they wear a college tie. Or shoes ;-)

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

On 8 March 2012 17:27, Len Bullard <Len.Bullard@ses-i.com> wrote:
> It’s a general qualifications question:  do you expect an XML professional to:
>
> Be able to correctly interpret DTD/Schema?
> Write or modify a DTD/Schema
> Code and/or test and modify XSLT.
> Program at least to a level of proficiency to build simple productivity
> tools (for example, basic querying of XML in some form)

If they're permitted free access to the Web for looking things up,
then sure. Standards work is all about knowing when and where to look
stuff up (and when to ask a friend instead).

cheers,

Dan

In a profession, you do the work applying the knowledge you obtain doing the
work.  If you learned application from a book even better.  That means
others will understand what you are doing if they read.  If they practice,
you can do it together.  If neither, you are in different professions.  

len

-----Original Message-----
From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan
Sent: Thursday, March 08, 2012 6:03 PM
To: Cox, Bruce
Cc: Michael Kay; xml-dev@lists.xml.org
Subject: Re:  Should XML Professionals Be Programmers?

Cox, Bruce scripsit:

> In graduate school (1980) we agreed that a professional is someone who
> will do the right thing based on extensive knowledge of the domain,
> whether or not the customer knows to ask for it.  Today, I'd say
> it this way: A professional is someone trusted to do the right thing
> based on extensive knowledge of the domain, whether or not the customer
> knows enough to ask for it.

I think it's also the case that in a profession you apply knowledge you
got from a book (basically).  In a job, being ditch-digging or being
President of the United States, you apply whatever you already have to
doing what needs to be done.

-- 
John Cowan  cowan@ccil.org  http://ccil.org/~cowan
If he has seen farther than others,
        it is because he is standing on a stack of dwarves.
                --Mike Champion, describing Tim Berners-Lee (adapted)

_______________________________________________________________________

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

I've just seen this:

http://anti-xml.org/

It isn't what you might first expect... does anyone have experience of using it?


cheers
andrew


-- 
Andrew Welch
http://andrewjwelch.com

Cox, Bruce scripsit:

> In graduate school (1980) we agreed that a professional is someone who
> will do the right thing based on extensive knowledge of the domain,
> whether or not the customer knows to ask for it.  Today, I’d say
> it this way: A professional is someone trusted to do the right thing
> based on extensive knowledge of the domain, whether or not the customer
> knows enough to ask for it.

I think it's also the case that in a profession you apply knowledge you
got from a book (basically).  In a job, being ditch-digging or being
President of the United States, you apply whatever you already have to
doing what needs to be done.

-- 
John Cowan  cowan@ccil.org  http://ccil.org/~cowan
If he has seen farther than others,
        it is because he is standing on a stack of dwarves.
                --Mike Champion, describing Tim Berners-Lee (adapted)

A patent application MUST disclose the invention in order to get a filing date; EVERYTHING else is optional at that stage.  However, before it can be examined, the application must have a long list of characteristics, including the inventor's name and mailing address.  Before an application can be allowed, certain other items become REQUIRED, and before publication, there must be evidence that the publication fee has been paid.  Some information in the published disclosure is not provided by the applicant, but by the Office.  The schema used at different stages for the same application will have a different mix of optional and required elements, or not even contain some elements at one stage that appear at a later stage, and even a few that disappear at the final stage.

Conversion of our legacy data usually requires a very relaxed schema, since over time, the trend has been to require more information, not less, from an applicant, and to publish more, not less, in the disclosure.  So, when converting from various ages in the past, the target schema will almost certainly contain every element needed for every age, but all but a handful will be declared optional.  Systems that process the legacy data might have to provide for the appropriate constraints based on the age of the document, while still working within a standard schema that is hardly more than a lattice work.

Bruce B Cox
OCIO/AED/Software Architecture and Engineering Division
571-272-9004


-----Original Message-----
From: Rudder, Doug Jr [mailto:Doug.Rudder@wolterskluwer.com] 
Sent: 2012 February 27, Monday 13:47
To: Costello, Roger L.; xml-dev@lists.xml.org
Subject: RE:  What does "optional" mean?

The answer can be very simple. For example, I work in drug information.
We have a standard section dealing with drug abuse/dependency, which is a vitally important section *when it applies*. However, many drugs are not problematic in this regard and the element is not necessary in those instances. Therefore, it is an optional element for a drug monograph.

Honestly, I've yet to see a DTD/Schema that did not contain optional elements, all of them important, but only within their intended context as described above.

To answer your revised question within the context of drug information, there are elements (e.g., Indications, Adverse Reactions) that are always mandatory in our monographs, but other elements (a variety of warnings and precautions) that, while common enough and important enough to warrant a "named" element, are not relevant to every single drug monograph and are therefore optional.

Another good example would be Black Box Warnings. This is potentially life-or-death information, but is optional because many drugs do not have them.

-----Original Message-----
From: Costello, Roger L. [mailto:costello@mitre.org]
Sent: Sunday, February 26, 2012 10:16 AM
To: xml-dev@lists.xml.org
Subject: RE:  What does "optional" mean?

> I would agree with David Carlisle.
> In schema,  "optional" doesn't mean ANY of the items you suggest.

Yes, I stand corrected. Despite my best efforts, how quickly and easily I fall into the trap of ascribing meaning to constructs in schemas.

Let me rephrase my question: 

       Why make one element mandatory 
      and another optional?

That is, what is it about some information that it is declared mandatory whereas another information is declared optional?

/Roger


_______________________________________________________________________

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

Is there a Chester County Militia?

Bruce B Cox
OCIO/AED/Software Architecture and Engineering Division
571-272-9004


-----Original Message-----
From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan
Sent: 2012 March 8, Thursday 16:56
To: Cox, Bruce
Cc: Len Bullard; Michael Hopwood; xml-dev@lists.xml.org
Subject: Re:  Should XML Professionals Be Programmers?

Cox, Bruce scripsit:

> If I were looking for my replacement, I’d be looking for a 
> philosopher, and if one with the necessary interest can’t be found, 
> then perhaps an English major.

Does it matter which regiment he commands?

-- 
If you understand,                      John Cowan
   things are just as they are;         http://www.ccil.org/~cowan
if you do not understand,               cowan@ccil.org
   things are just as they are.

Cox, Bruce scripsit:

> If I were looking for my replacement, I’d be looking for a
> philosopher, and if one with the necessary interest can’t be found,
> then perhaps an English major.  

Does it matter which regiment he commands?

-- 
If you understand,                      John Cowan
   things are just as they are;         http://www.ccil.org/~cowan
if you do not understand,               cowan@ccil.org
   things are just as they are.

Yes.   Programming productivity was a lot less before I could find examples.  On the other hand, finding a quality example can be problematic.  A case in point:  how many ways are there to write a search and replace in VB?  ;)  A little more seriously, how many times has one copied code only to discover the framework classes it requires a) didn't work well or b) are no longer supported in VSpickaversion.  Sometimes Google gives an answer but as the old professor told them in a lawyer show from years ago, "the first answer is seldom the complete answer".

A little off topic... I was wondering if what I am hearing is normal because some of this stuff defies everything I thought I knew about XML production work.  In general, I would expect four of those skills from someone hired to do XML work.  I know it 'depends' but I would expect it and if told "we don't pay our XML people to program", I'd worry because of the productivity possible from someone who can.

len

-----Original Message-----
From: Dan Brickley [mailto:danbri@danbri.org] 
Sent: Thursday, March 08, 2012 1:55 PM
To: Len Bullard
Cc: xml-dev@lists.xml.org
Subject: Re:  Should XML Professionals Be Programmers?

On 8 March 2012 17:27, Len Bullard <Len.Bullard@ses-i.com> wrote:
> It's a general qualifications question:  do you expect an XML professional to:
>
> Be able to correctly interpret DTD/Schema?
> Write or modify a DTD/Schema
> Code and/or test and modify XSLT.
> Program at least to a level of proficiency to build simple productivity
> tools (for example, basic querying of XML in some form)

If they're permitted free access to the Web for looking things up,
then sure. Standards work is all about knowing when and where to look
stuff up (and when to ask a friend instead).

cheers,

Dan

Michael Hopwood scripsit:

> Yes, fair points. How far does the term "data architect" sum up some of
> these? I guess it relates to being able to design schemas / transforms
> that take into account all of these. And the focus is on the data,
> and its structure here. In the library world, we pretty much call
> that cataloguing, or systems librarianship. But then our schemas move
> pretty slowly...

I'm going to put "Ontologist" on my tax returns this year and see what
the IRS makes of it.

-- 
Mark Twain on Cecil Rhodes:                    John Cowan
I admire him, I freely admit it,               http://www.ccil.org/~cowan
and when his time comes I shall                cowan@ccil.org
buy a piece of the rope for a keepsake.

I agree, John.  And a very productive one.

They may not need to program in other languages but it is helpful.  If
someone can't read a DTD to some level of proficiency, I have some
qualms about their skill set given an environment where tagging in a
DTD-enabled editor is not enough to solve problems.  Sometimes the task
is proving where a problem originates; otherwise, one is solving the
wrong problem.  The same is true of the XSL.

An "XML guru" came to me one day and pointed out that half of a document
was missing.   I asked if he had inspected the file.  He asked me why he
should do that, it was missing.  What was missing was a right quotation
mark.  The XML editor told him the file wasn't XML.  An "XML guru" that
doesn't know what that means can't go to the next task because they
simply don't know what that error means.  A competent XML skilled
individual knows that in most cases, Draco has struck and they start
looking for a syntax error.

On the other hand, if one finds a fully-qualified pathname in an ENTITY
attribute, one might look elsewhere.   If one is given a document full
of empty ENTITY attributes, one might look elsewhere.

len

-----Original Message-----
From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan
Sent: Thursday, March 08, 2012 10:58 AM
To: Michael Kay
Cc: xml-dev@lists.xml.org
Subject: Re:  Should XML Professionals Be Programmers?

Note to Len:  Writing and debugging XSLT *is* programming.  Anyone who
can learn to program in XSLT can learn to program in any other language.

Michael Kay scripsit:

> There's no such thing as an XML professional, any more than you can be a  
> screwdriver professional or a fork-lift truck professional. People who  
> define their abilities by the tools they can use proficiently are not  
> professionals, they are technicians; professionals define their  
> capabilities in terms of the problem space, not the solution space.

Quoted for truth.

Note that _qualified_ has different meanings on opposite sides of the
Pond.  Where a Brit may say

	He's qualified, but can he do the work?

a Yank may express the same thought with

	He has the credentials, but is he qualified to do the work?

Note to Len:  Writing and debugging XSLT *is* programming.  Anyone who
can learn to program in XSLT can learn to program in any other language.

-- 
I Hope, Sir, that we are not                    John Cowan
mutually Un-friended by this                    cowan@ccil.org
Difference which hath happened                  http://www.ccil.org/~cowan
betwixt us.     --Thomas Fuller, Appeal to Injured Innocence