On Feb 6, 2012, at 10:28 PM, Greg Hunt wrote:

>   The language and culture in the business domain are the only
> things that over time resist the entropy that developers naturally bring to
> the design and maintenance of shared data structures.

Color me, hmmm, out-of-touch, but... in what world does such an orderly, well defined, stable, never changing, clear, unambiguous "business domain" exists?!?! 

If anything, the, hmmm, real world is anything but orderly.

Uche Ogbuji scripsit:

> If that were the case then writing XML parsers would not be one of the more
> challenging tasks any programmer can face.

I wouldn't call it challenging; it's just full of unfortunate corner cases.
Writing a C++ parser, now that's challenging.

-- 
He made the Legislature meet at one-horse       John Cowan
tank-towns out in the alfalfa belt, so that     cowan@ccil.org
hardly nobody could get there and most of       http://www.ccil.org/~cowan
the leaders would stay home and let him go      --H.L. Mencken's
to work and do things as he pleased.              Declaration of Independence

On Feb 6, 2012, at 5:36 PM, Costello, Roger L. wrote:

> The convenience of a programmer should not be placed over the readability of the data... Business users take precedence over programmer convenience.

ROTFLMAO :D

Original Message From: "Cox, Bruce"
>
> Java developers have frequently complained of this, since the
> hyphen is apparently a reserved character in Java and their
> tools for automatically creating classes stumble over them
> when used in element names, requiring manual intervention,
> or other cleanup actions (so I’m told).
>
> Is the Java objection real?  Is there any real technical reason
> to prefer one over the other?

Our C++ data binding tool will convert hyphens in a name to underscores.
You can also specify whether you would like underscore/hyphen_separated
names converted to CamelCase, or vice versa.  This latter process is a bit
heuristic and may not always produce what people expect or want, but I see
no reason why other tools can't support it.  (There's also a completely
manual option.)  Naturally you have to make sure that there are no name
clashes after the conversion. Actually, if you put each class in its own
file you have to make sure that there are no name clashes when case is
ignored as the Windows system is not case sensitive.  It's all just part of
the job!

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: "Cox, Bruce" <Bruce.Cox@USPTO.GOV>
To: "Uche Ogbuji" <uche@ogbuji.net>; <xml-dev@l...>
Sent: Monday, February 06, 2012 3:57 PM
Subject: RE:  Should one adopt the tag naming convention of an
existing XML vocabulary or create one's own tag naming convention?


> WIPO Standard ST.36, vocabulary for patent documents, uses hyphen
> separators rather than underscore or camel case.  Java developers have
> frequently complained of this, since the hyphen is apparently a reserved
> character in Java and their tools for automatically creating classes
> stumble over them when used in element names, requiring manual
> intervention, or other cleanup actions (so I’m told).
>
> Is the Java objection real?  Is there any real technical reason to prefer
> one over the other?
>
> Personally, I find hyphenated element names easier to read than camel
> case, and vastly easier to type than underscores.
>
> In general, I’m in the same camp as many others with regard to the source
> of element names: the business vocabulary takes precedence.  We also try
> to follow ISO 11179-5, but where there is the slightest chance the results
> will confuse or snag the business users, we break those rules without
> hesitation.
>
> Bruce B Cox
> OCIO/AED/SAED
> 571-272-9004
>
> From: Uche Ogbuji [mailto:uche@ogbuji.net]
> Sent: 2012 February 3, Friday 15:18
> To: xml-dev@lists.xml.org
> Subject: Re:  Should one adopt the tag naming convention of an
> existing XML vocabulary or create one's own tag naming convention?
>
> On Fri, Feb 3, 2012 at 1:11 PM, Andrew Welch
> <andrew.j.welch@gmail.com<mailto:andrew.j.welch@gmail.com>> wrote:
>> Here are two possibilities:
>>
>> 1. I will create a my own tag naming convention, independent of the XML
>> vocabularies that I will use.
>>
>> 2. I will adopt the tag naming convention of one of the XML vocabularies
>> that I will use. (Which one?)
>>
>> What do you recommend?
>
>
> There is only one way :) names should be all lower-case, with hyphen
> as a separator.  Camel case, or any thing else really, are awful for
> xml.
>
> I strongly agree, but of course this one is a very subjective matter. I
> curse Java for its propagation of the CamelCase eyesore.
>
> --
> Uche Ogbuji                       http://uche.ogbuji.net
> Weblog: http://copia.ogbuji.net
> Poetry ed @TNB: http://www.thenervousbreakdown.com/author/uogbuji/
> Founding Partner, Zepheira        http://zepheira.com
> Linked-in: http://www.linkedin.com/in/ucheogbuji
> Articles: http://uche.ogbuji.net/tech/publications/
> Friendfeed: http://friendfeed.com/uche
> Twitter: http://twitter.com/uogbuji
> http://www.google.com/profiles/uche.ogbuji
>

>> I was also looking for beginners' guides

The book I recommended for years was "XML: A Manager's Guide" by Kevin 
Dick. I doubt that someone has more recently written a better book for 
XML beginners.

Portions of Kevin's book are available via Google Books here:

http://books.google.com/books?id=nLslZRunKDsC&pg=PA300&lpg=PA300&dq=Kevin+Dick+XML&source=bl&ots=2d5ocBV7yC&sig=hEs-7HT7H7T8mdYgxV_RpygJXGc&hl=en&sa=X&ei=ZUswT-vFPOeRiQLpjZmRAw&ved=0CB4Q6AEwAA#v=onepage&q=Kevin%20Dick%20XML&f=false



Ken North
________________
www.kncomputing.com
@knorth2
kncomputing.tumblr.com

 

Hi Folks,

Excellent discussion!

Below is a summary of the discussion. Have I captured everything? Do you agree with the recommendations?

---------------
Introduction
---------------

What convention should one use to name elements and attributes -- camel case, lower-case dash-separated, or something else? 

When reusing several XML vocabularies, each using a different naming convention, what convention should one use to name one’s own markup? 

Naming is just one issue when creating an XML vocabulary, there are also schema structural issues, terminology issues, and others. A Naming and Design Rules (NDR) document specifies the conventions for each issue. 

When reusing several XML vocabularies, each conforming to a different NDR, what NDR should one use for one’s own XML vocabulary? 

The purpose of this message is to provide answers, or at least options, for each of these questions.

--------------------
Naming Markup
--------------------

The XML specification is silent on how to create element and attribute names (markup names). Further, there is no industry standard on naming markup. Some commonly used conventions for naming markup include: 

-  Camel case: if a name contains multiple words then they are smashed together with the first letter of each word (except the first) in upper case. Examples: <jetFuel>, <airRefuelingRequest>.

-  Lower case, dash-separated: each word in a name is lower case and words are separated by a dash. Examples: <jet-fuel>, <air-refueling-request>.

-  Lower case, underscore-separated: each word in a name is lower case and words are separated by an underscore. Examples: <jet_fuel>, <air_refueling_request>.

Here is a sampling of naming conventions used by W3C and ISO technologies:

1.  XML Schema: elements and attributes are camel case. Examples: maxOccurs, elementFormDefault, substitutionGroup.

2.  XSLT: elements and attributes are lower case, dash-separated. Examples: apply-templates, exclude-result-prefixes, analyze-string.

3.  Schematron: most elements and attributes are a single, lower case word (e.g., assert, rule, pattern). There is an element and an attribute with multiple words (value-of, is-a). There are two elements that use camel case (queryBinding and defaultPhase).

Interestingly, XML Schema and XSLT -- both W3C technologies -- use different naming conventions. And Schematron -- an ISO technology -- is not entirely consistent in its naming convention.

Some developers argue against using dash-separated names. Their argument is that when XML is auto-converted (using a data binding tool) into a programming language syntax then the programming language compiler or interpreter may misinterpret a dash as a subtraction operator. However there are counterarguments:

-  When converting XML to programming language syntax it is easy to systematically remove the dashes, if necessary. For example, map Jet-Fuel to JetFuel or Jet_Fuel.

-  The convenience of a programmer should not be placed over the readability of the data. Hyphens and underscores make markup easier for non-programmers to read. Business users take precedence over programmer convenience.

Note that misinterpreting dashes in markup names for the subtraction operation is not an issue when using XML-aware tools such as XSLT, XML Schema, Relax NG, Schematron, and XQuery as they handle XML names properly.

Whatever naming convention one adopts, it is important to stick with it and be consistent in naming markup. 

---------------------------------------------------------------------------------
Reuse XML Vocabularies, each uses a Different Naming Convention
---------------------------------------------------------------------------------

As noted in the previous section, not every XML vocabulary uses the same markup naming convention. Even within the W3C there is variance (XML Schema uses camel case whereas XSLT uses lower case, dash-separated). 

What should one do when reusing several XML vocabularies, each using a different naming convention? XML instances consist of locally created markup and markup from external XML vocabularies. For the locally created markup, what naming convention should be used? 

Here are three options:

1.  Create a naming convention independent of the external XML vocabularies.

2.  Adopt the naming convention of one of the external XML vocabularies. (Which one?)

3.  Create a naming convention that is in harmony with the external XML vocabularies. For example, suppose the XML vocabularies being reused are XML Schema and XSLT. XML Schema defines “things” and uses camel case. XSLT defines “actions” and uses lower case, dash-separated. Thus, for locally created markup use camel case for “things” and lower case, dash-separated for “actions.”

Local practice may conflict with external practice. The key point is to create a naming convention that is suitable for one’s user community. Adopt a convention that balances consistency and existing local practice to minimize mental gear-changing by the users.  The convention should make the names "feel" consistent for users.

------------------------------------------------------------------------------------------
Reuse XML Vocabularies, each has Different Naming & Design Rules (NDR)
------------------------------------------------------------------------------------------

The previous discussion is now generalized. Naming convention is only one issue (a large one, but only one). Other conventions are also important, such as a schema structural convention and a terminology convention. 

A Naming and Design Rules (NDR) is a document that specifies the naming convention to be used when creating an XML vocabulary, schema stylistic issues (optionality, indications of list length), and terminology (simple words like order, list, and part may mean different things in different parts of a user community). Many NDR specifications have been created: 

-	ACORD Naming and Design Rules (NDR)
-	Danish XML Project: OIOXML Naming and Design Rules
-	EPA Exchange Network XML Design Rules and Conventions
-	Federal XML Naming and Design Rules Project
-	Global Justice XML Data Model (GJXDM) Naming and Design Rules
-	Hong Kong OGCIO Interoperability Framework for E-Government
-	 IRS XML Naming and Design Rules
-	OAGIS Naming and Design Rules (NDR)
-	OASIS LegalXML Exchange Document Methodology, Naming, and Design Rules (MNDR) Subcommittee
-	Universal Business Language (UBL) Naming and Design Rules
-	UN/CEFACT XML Naming and Design Rules Technical Specification
-	US Department of the Navy XML Naming and Design Rules
-	US National Information Exchange Model (NIEM) NDR

See the Cover Pages (http://xml.coverpages.org/ndr.html) for a description of each NDR.

What should one do when reusing several XML vocabularies, each conforming to a different NDR? How should one design a schema that reuses several external schemas, each conforming to a different NDR? Which NDR should be used? 

The options are similar to those described in the previous section.

1.  Create an NDR independent of the external XML vocabularies.

2.  Adopt the NDR of one of the external XML vocabularies. (Which one?)

3.  Create an NDR that is in harmony with the NDRs used by the external XML vocabularies. This involves harmonizing a naming convention (see the previous section for a brief description of how to do this), schema structural issues, and terminology issues.

Local practice may conflict with external NDRs. Favor local practice. If an external vocabulary conforms to an NDR that has rules which are inconsistent with one’s user community then don’t use those rules.

PCDATA element type and CDATA attribute type

This seems to be a good old question asked a lot and often answered
incorrectly outside this mailing list. Please correct me if I'm wrong
in the following.

Having an element type called PCDATA and an attribute type called
CDATA is misleading since they are exactly the same for all practical
purposes. They are both parsed in the sense that character references
are replaced with the character and named references are expanded and
in the sense that we get wellformedness errors in both if they contain
markup?

One could just as well have decided to call both PCDATA or CDATA. The
background for the two types are probably that it was called PCDATA
for elements to contrast it with a CDATA section escaping markup ...
forgetting to call it PCDATA also in attributes. A more sensible
working group would probably have decided for having just one "string"
data type to be used in both elements and attributes, and just one
name.

The only real difference I can think of is that the CDATA attribute
type ends up partly whitespace normalized, linefeeds becoming just
spaces. But this is more a question of being an attribute and an
element than of having two types.  Also, in attributes we can't use
quotation marks directly except if we delimit the attribute value with
apostrophes instead of quotation marks.

Do we have any real differences after all?

Cheers
Jesper Tverskov

On 06/02/2012 15:31, Jesper Tverskov wrote:
> The only real difference I can think of is that the CDATA attribute
> type ends up partly whitespace normalized, linefeeds becoming just
> spaces. But this is more a question of being an attribute and an
> element than of having two types.

Well there's the rub, similarly < is parsed differently in the two 
cases; starting an element tag in one case and not the other. So the 
parsing is actually quite different, it only appears to be the same if 
you ignore the obvious differences...

But the real reason for the silly names is that they were called that in 
SGML (which had more possibilities and variants so the names made more 
sense there) so the names were a given since XML being an SGML subset 
was a hard(ish) requirement.

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. 
________________________________________________________________________

It is a paid up reality.  As for chest thumping, let the turbo driven  
rotors do that.  It's green here; not gray at least since 1865.

I've yet to see WordPress produce a mil-spec TM for republishing into  
a variety of XML-derived publications.  I suppose it could be done but  
why?

The tool should fit the process and the upstream resources.  If one  
takes a job where they use Word, one processes Word first.  If not,  
don't.  XML doesn't care but XML tools do.  Mostly programmers do but  
like the rest of us, they have their prejudices and those are often  
reflected in the tools they choose and the code they write.  Given a  
mass distribution engine like the web, those prejudices can easily and  
rapidly become "best practice" for some n of the available conscripts.  
  In the eyes of many a programmer, XML is considered a "best  
practice" of just that sort.

Erik Naggum made a career of making that point.

The answer to the topic is, yes, if the locals don't mind.

len


Quoting Uche Ogbuji <uche@ogbuji.net>:

> On Mon, Feb 6, 2012 at 10:53 AM, <cbullard@hiwaay.net> wrote:
>
>> Reality check, Uche: a not insignificant number of people giving us
>> documents are using Microsoft Word.  Like it or not, that's where the
>> information is; so, solving problems of that conversion is the first task
>> on the stack, not the last one.  It isn't a hard one but it comes with
>> surprises. The best tool does the job I need it do and doesn't get in the
>> way.
>>
>
> That's your reality. Enjoy it. It's still entirely beside the point.
>
> I'd say that the number of people authoring XMLish stuff through Web forms
> (e.g. WordPress) has grown past those doing so in your grey industrial
> bureaus. So if you insist on an argument from high authority, I'll just
> puff up my chest and thump my own H.A. as well. I suspect that won't get us
> very far.
>
>
> There is a full copy of Arbortext Editor on my desktop here at work.  I
>> open the document in it from time to get error reports and to create PDF.
>>  Like so many editors, it leaks memory and crashes the desktop, takes a
>> very long time to render and has a very awkward means of entering attribute
>> values.  The treeview is almost useless.
>>
>> The attempt to be both an XML/SGML editor and a WYSIWYG editor is on my
>> list of overbuilt.  It is a lot faster to build a form that sequences
>> documents in response to queries, checks syntax and validates and on
>> request, renders to a reasonable facsimile in an embedded browser in a
>> separate tab.  Otherwise, the XML in XML is a fine GUI for editing.  I
>> know, Oxygen is a good editor.  Get it past the procurement folk who vette
>> sources before they will install software on the machines behind the
>> firewalls.
>>
>
> Why? I don't really care to do so. Nor do I need to.
>
>
> --
> Uche Ogbuji                       http://uche.ogbuji.net
> Weblog: http://copia.ogbuji.net
> Poetry ed @TNB: http://www.thenervousbreakdown.com/author/uogbuji/
> Founding Partner, Zepheira        http://zepheira.com
> Linked-in: http://www.linkedin.com/in/ucheogbuji
> Articles: http://uche.ogbuji.net/tech/publications/
> Friendfeed: http://friendfeed.com/uche
> Twitter: http://twitter.com/uogbuji
> http://www.google.com/profiles/uche.ogbuji
>

The history of XML from day 1 has been about the convenience of  
programmers or near-programmers, the infamous DePH.

It took marketing to make it about customer needs.  The embedded  
context is in those text nodes that we mostly ignore.

len


Quoting Greg Hunt <greg@firmansyah.com>:

> Isn't this the example in point?  The world revolves around developers and
> the geometry gets a bit strange when there is more than one (well, more
> than one distinct developer culture).  The XML that matters is the XML that
> is shared and then it is embedded in some business context with its own
> language and culture and needs to conform with the language and culture to
> remain easily shareable.  If its not shared, then the tools are what
> matter.

> In order to test exhaustively this library, we need to have XML data sets
> that have data quality problems known a priori.
> By data quality problems, we mean: missing values, misspellings, synonyms,
> values out of domain, approximate duplicates, etc.


Government data:  http://data.gov.uk/data

I did a short contract for 'LinkedGov' a while back
(http://linkedgov.org/), it's their goal to make the data clean and
usable, so you might want to get in touch with them.



-- 
Andrew Welch
http://andrewjwelch.com

On Mon, 2012-02-06 at 08:29 -0700, Uche Ogbuji wrote:
[...]
> Since none of us use computers by flipping dip switches any more, we all
> need software tools. 

Hey, speak for yourself! How else to get the LSI11-02 to boot and
recognise the paper tape reader?

The problem I'm having right now with XPath is that there's no { or } in
the character set.  The V6 Unix drivers used to understand ( backspace -
as a curly brace, but ...

...oh wait, I was sleepmailing again, I'm waking up now...

:-)

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

Thanks to Norm Birkett for his recommendations - I was also looking for beginners' guides.

Could anyone here recommend any sort of XML / schema/ontology-related course or certificate that one might take - possibly online?

Something quite practically-oriented would be perfect.

Thanks,

Michael 

-----Original Message-----
From: Norm Birkett [mailto:Norm.Birkett@reval.com] 
Sent: 02 February 2012 15:16
To: xml-dev@lists.xml.org
Subject: RE:  book for beginners

Catching up on the list after a prolonged distraction, I see no one has replied to your query. As a newcomer to XML myself, I can recommend the following--not because they're perfect, but merely because they helped me come up to my present speed (which, granted, isn't at all dizzying--but it's enabling me to function in a setting in which I have to interact with XML etc. just frequently enough to mean I need to know it, and just infrequently enough to make it hard to remember):

(Step 1) Study in tandem:

* Kevin Howard Goldberg, XML (2nd ed.) -- in the Visual Quickstart Guide series, which I detest, but this one worked for me
* Simon St. Laurent & Michael Fitzgerald, XML Pocket Reference (3rd. Edition)

(Step 2) If your interests lie anywhere in the direction of EITHER of the technologies mentioned in its title, then buy a copy of this one, study the introductory bits (throughout), and keep it by your side at all times:

* Michael Kay, XSLT 2.0 and XPath 2.0 Programmer's Reference (4th ed.) -- Wrox

(Meanwhile) 

* Follow this mailing list and the XSL list (at mulberrytech.com). Much of the discussion will be over your head, but you will learn all manner of fascinating bits and pieces along the way--and most important, you'll get a feel for the real XML world. (The books, for example, might lead you to wonder why anyone in his right mind would write XML Schema for anything. The lists will tell you that no one does unless forced to by some fairly compelling and unusual set of circumstances.)

* I also follow the schematron and relax ng lists, but they're not very active. I can't tell if that's because hardly anyone uses those technologies, or because those who do don't have many questions.

Warning: The preceding recommendations are based on a sample size of one, which should not be considered representative.

Norm Birkett

> -----Original Message-----
> From: Bob Jolliffe [mailto:bobjolliffe@gmail.com]
> Sent: Wednesday, January 04, 2012 4:02 AM
> To: xml-dev@lists.xml.org
> Subject:  book for beginners
> 
> Does anyone have any book recommendations for a beginner student which 
> covers the *fundamentals* of xml validation and processing?  Bearing 
> in mind I guess that people would have different ideas of what is 
> fundamental.  I would think a good overview should touch upon DTDs, 
> W3C Xml Schema, RelaxNg, Schematron, NVDL, Xpath, Xslt, Xquery, XProc.

In the mil world, there is still a lot of document applications  
developed in Word and delivered in XML/PDF.  The document authoring  
realm is pretty big in terms of people doing it.  There are different  
notions of convenience.

I look at the ponderous 1500 page docs we deliver in rich tagged  
formats and then I look at the itty bitty messages in pointy brackets  
that might better be handled as JSON or even CSV and I wonder about  
the trendyness of the next new thing.  We probably didn't do the  
programmers a huge favor with insisting on wall to wall XML but the  
longest lived XML (lifecycle) and most expensive per tag is almost  
always a document.

I don't think too many human beings are reading the XML we deliver.   
They are validating it, inspecting the choices made given the options  
in the DTD polyglot then sending us long memos in Word telling us what  
they actually prefer, nay, insist on despite the face that all the  
CDRL cited was a document with best practices that cite the DTD in a  
separate document with a single line citation and no other details.   
Then they pass it on to the people with the software to slice and dice  
it into multiple products.

The majority is exchanging and reading the Word files.

len

Quoting Alex Muir <alex.g.muir@gmail.com>:

> On Mon, Feb 6, 2012 at 4:36 PM, Costello, Roger L. <costello@mitre.org>wrote:
>
> Seems to me this all depends...
>
>> The convenience of a programmer should not be placed over the readability
> of the data.
>> Business users take precedence over programmer convenience.
>
> I would agree with this if say writing docbook or dita where someone pseudo
> technical is getting into the xml but outside of the document authoring
> realm I would think you would want to "balance convenience with readability"
>
> What is an example of a business user then? Docbook author? I would think a
> large percentage of the business users of xml people I assume who gain some
> benefit of a xml process occurring on a server somewhere that makes them
> money can't read xml and don't care to and would rather read the resulting
> website or document content. No?
>
>
> -- XML is so versatile so would the markup be. --
>
>
> --
> Alex Muir
> Program Organizer - University Technology Student Work Experience Building
> University of the Gambia
> http://sites.utg.edu.gm/alex/<https://sites.google.com/a/utg.edu.gm/utsweb/>
>
> Come visit Gambia enjoy the sun and culture and help out! Software
> Engineering Lecturers needed!
> Join UTSWEB do local contract work or give a student a contract remotely
> for slow, cheap and good work
> http://sites.utg.edu.gm/utsweb/<https://sites.google.com/a/utg.edu.gm/utsweb/>
>
> Some fantastic African/Canadian Fusion  *http://bafila.bandcamp.com/*
>

Reality check, Uche: a not insignificant number of people giving us  
documents are using Microsoft Word.  Like it or not, that's where the  
information is; so, solving problems of that conversion is the first  
task on the stack, not the last one.  It isn't a hard one but it comes  
with surprises. The best tool does the job I need it do and doesn't  
get in the way.

There is a full copy of Arbortext Editor on my desktop here at work.   
I open the document in it from time to get error reports and to create  
PDF.  Like so many editors, it leaks memory and crashes the desktop,  
takes a very long time to render and has a very awkward means of  
entering attribute values.  The treeview is almost useless.

The attempt to be both an XML/SGML editor and a WYSIWYG editor is on  
my list of overbuilt.  It is a lot faster to build a form that  
sequences documents in response to queries, checks syntax and  
validates and on request, renders to a reasonable facsimile in an  
embedded browser in a separate tab.  Otherwise, the XML in XML is a  
fine GUI for editing.  I know, Oxygen is a good editor.  Get it past  
the procurement folk who vette sources before they will install  
software on the machines behind the firewalls.

This is an XML list that discusses Java, Javascript, PHP, even Lisp on  
occasion.  Tools is tools.  Notepad++ with syntax highlighting turned  
on gets a lot of useful work done for very little footprint.  That  
said, I still built my own editor from spare parts.  An illuminating  
exercise...

len

Quoting Uche Ogbuji <uche@ogbuji.net>:

> Boy you are confusing me. We're talking about better tools and you bring up
> MS Word? This is an XML list.
>
> Since none of us use computers by flipping dip switches any more, we all
> need software tools. A "better" tool is one that makes you a better user of
> your technology of focus. In the case of XML, if you are going to rely a
> tool to select a token for you, i.e. via double-clicking a name, then a
> "better" tool is one that knows what and where such a token is in XML.
>
> --Uche
>
> On Mon, Feb 6, 2012 at 7:15 AM, <cbullard@hiwaay.net> wrote:
>
>> Some better tools are overbuilt, old or don't have the functionality I
>> need baked in.   There is also a lot to learn from building tools, but more
>> importantly, when one can build the tool from the toolkit builder, one can
>> customize it to the precise conditions of the job.  They don't always
>> support a fast batch change and at crunch time, that ability pays dividends.
>>
>> There is nothing shabby about clicking on an element name and the search
>> term showing up in the search box.
>>
>> So called better tools are also a reason for "taggers" who know almost
>> nothing about XML.  They don't exactly impress me because we have to deal
>> with their inability to solve simple problems.  They don't understand why
>> cutting and pasting out of Word directly into an XML editor can create
>> problems.
>>
>> len
>>
>> Quoting Uche Ogbuji <uche@ogbuji.net>:
>>
>>  On Sun, Feb 5, 2012 at 9:21 AM, Len Bullard <cbullard@hiwaay.net> wrote:
>>>
>>>   "How often do you really click to cut and paste just an element name?"
>>>>
>>>>
>>>>
>>>> Quite a lot.    *Usually when searching.  It sets the term in the search
>>>> box.*
>>>>
>>>>
>>>>
>>>> 1 click to select a word is best practice in Notepad++ and with XML
>>>> language selected, to highlight the element name and close for fast
>>>> scanning of the tree in the text.
>>>>
>>>>
>>> Well then, as others have pointed out, you need to use better tools. It's
>>> not something I know about because it's not a problem I've ever had, but
>>> if
>>> I did, I'd certainly blame my tools, not the vocabulary design.
>>>
>>>
>>> --
>>> Uche Ogbuji                       http://uche.ogbuji.net
>>> Weblog: http://copia.ogbuji.net
>>> Poetry ed @TNB:  
>>> http://www.**thenervousbreakdown.com/**author/uogbuji/<http://www.thenervousbreakdown.com/author/uogbuji/>
>>> Founding Partner, Zepheira        http://zepheira.com
>>> Linked-in:  
>>> http://www.linkedin.com/in/**ucheogbuji<http://www.linkedin.com/in/ucheogbuji>
>>> Articles:  
>>> http://uche.ogbuji.net/tech/**publications/<http://uche.ogbuji.net/tech/publications/>
>>> Friendfeed: http://friendfeed.com/uche
>>> Twitter: http://twitter.com/uogbuji
>>> http://www.google.com/**profiles/uche.ogbuji<http://www.google.com/profiles/uche.ogbuji>
>>>
>>>
>>
>>
>
>
> --
> Uche Ogbuji                       http://uche.ogbuji.net
> Weblog: http://copia.ogbuji.net
> Poetry ed @TNB: http://www.thenervousbreakdown.com/author/uogbuji/
> Founding Partner, Zepheira        http://zepheira.com
> Linked-in: http://www.linkedin.com/in/ucheogbuji
> Articles: http://uche.ogbuji.net/tech/publications/
> Friendfeed: http://friendfeed.com/uche
> Twitter: http://twitter.com/uogbuji
> http://www.google.com/profiles/uche.ogbuji
>

Original Message From: "Peter Flynn":

> The US 
> internal market is so large, and American SMEs (and some even bigger 
> ones) do so well out of it, that they have no need for foreign clients. 
> Not only do they not know where Europe is, but they actually don't give 
> a damn anyway.

Here's an amusing summary of the debate from a tweet I saw today!

https://twitter.com/#!/steipete/status/166412475321946112/photo/1

Pete.
--
=============================================
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: "Peter Flynn" <peter@silmaril.ie>
To: <xml-dev@lists.xml.org>
Sent: Saturday, February 04, 2012 9:34 PM
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication


> On 03/02/12 11:03, Pete Cordell wrote:
>> Welcome to XML Celebrity Slamdown!
>>
>> I'm giving the contestants 1 point each.
>>
>> One to Michael for mentioning American purchasing systems. I'm amazed
>> that very large American companies' purchasing systems still require you
>> to enter a US State and a phone number in the North American numbering
>> plan format. Lack of international awareness (or lack of international
>> concerns) is not a 20 year-old historical artefact.
> 
> It's not really surprising, no matter how annoying it is. The US 
> internal market is so large, and American SMEs (and some even bigger 
> ones) do so well out of it, that they have no need for foreign clients. 
> Not only do they not know where Europe is, but they actually don't give 
> a damn anyway.
> 
> There are also the barriers erected to cross-Atlantic business by the US 
> government *and* the EU authorities. US companies can't just ship goods 
> out by taking a parcel to the post office and sticking a stamp on it. 
> There are forms and rules and regulations designed to make it hard.
> 
> The well-known US multinationals do of course know all this, and happily 
> sell abroad, often well-disguised by localisation, but they still make 
> the same mistakes. Fortunately their forms are easy to fool.
> 
>> One to Len because I don't believe Unix would have got us to where we
>> are today.
> 
> Unix as it was certainly never would have:fragmented, expensive, and 
> laughably incompatible with everything except itself. And fat and 
> self-centred and complacent: they never saw Linux coming.
> 
> ///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
>

Jesper Tverskov scripsit:

> Having an element type called PCDATA and an attribute type called
> CDATA is misleading since they are exactly the same for all practical
> purposes. They are both parsed in the sense that character references
> are replaced with the character and named references are expanded and
> in the sense that we get wellformedness errors in both if they contain
> markup?

In CDATA, a < character is not interpreted as the beginning of markup.
This is true of both CDATA attributes (where it's an error) and CDATA
sections (where it is treated as a literal).

> One could just as well have decided to call both PCDATA or CDATA. The
> background for the two types are probably that it was called PCDATA
> for elements to contrast it with a CDATA section escaping markup ...
> forgetting to call it PCDATA also in attributes. A more sensible
> working group would probably have decided for having just one "string"
> data type to be used in both elements and attributes, and just one
> name.

The XML WG was constrained by SGML, where CDATA elements are also
possible.  The HTML SCRIPT and STYLE elements were originally declared
as CDATA, but they are now terminated only by the appropriate end-tag,
whereas SGML CDATA is terminated by any end-tag (and then it's an error
if it's the wrong one).

-- 
Possession is said to be nine points of the law,                John Cowan
but that's not saying how many points the law might have.       cowan@ccil.org
        --Thomas A. Cowan (law professor and my father)

Some better tools are overbuilt, old or don't have the functionality I  
need baked in.   There is also a lot to learn from building tools, but  
more importantly, when one can build the tool from the toolkit  
builder, one can customize it to the precise conditions of the job.   
They don't always support a fast batch change and at crunch time, that  
ability pays dividends.

There is nothing shabby about clicking on an element name and the  
search term showing up in the search box.

So called better tools are also a reason for "taggers" who know almost  
nothing about XML.  They don't exactly impress me because we have to  
deal with their inability to solve simple problems.  They don't  
understand why cutting and pasting out of Word directly into an XML  
editor can create problems.

len

Quoting Uche Ogbuji <uche@ogbuji.net>:

> On Sun, Feb 5, 2012 at 9:21 AM, Len Bullard <cbullard@hiwaay.net> wrote:
>
>>  "How often do you really click to cut and paste just an element name?"
>>
>>
>>
>> Quite a lot.    *Usually when searching.  It sets the term in the search
>> box.*
>>
>>
>>
>> 1 click to select a word is best practice in Notepad++ and with XML
>> language selected, to highlight the element name and close for fast
>> scanning of the tree in the text.
>>
>
> Well then, as others have pointed out, you need to use better tools. It's
> not something I know about because it's not a problem I've ever had, but if
> I did, I'd certainly blame my tools, not the vocabulary design.
>
>
> --
> Uche Ogbuji                       http://uche.ogbuji.net
> Weblog: http://copia.ogbuji.net
> Poetry ed @TNB: http://www.thenervousbreakdown.com/author/uogbuji/
> Founding Partner, Zepheira        http://zepheira.com
> Linked-in: http://www.linkedin.com/in/ucheogbuji
> Articles: http://uche.ogbuji.net/tech/publications/
> Friendfeed: http://friendfeed.com/uche
> Twitter: http://twitter.com/uogbuji
> http://www.google.com/profiles/uche.ogbuji
>

Sacrilege!
Unix is the root of all hints holy
The rest is Satan's  spawn

Sent from my iPad (excuse the terseness) 
David A Lee
dlee@calldei.com


On Feb 5, 2012, at 4:04 PM, "Michael Kay" <mike@saxonica.com> wrote:

> On 05/02/2012 16:09, Len Bullard wrote:
>> The key feature for web emergence was not the operating system.
> You've forgotten the context. About 1000 messages ago in this thread you asserted that Microsoft was the trigger for the collapse of vertical integration in our industry; I countered that the collapse happened earlier, and Unix was the trigger. We weren't talking about the emergence of the web or the significance of Unix today.
> 
> 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
> 
> 

On 05/02/2012 16:09, Len Bullard wrote:
> The key feature for web emergence was not the operating system.
You've forgotten the context. About 1000 messages ago in this thread you 
asserted that Microsoft was the trigger for the collapse of vertical 
integration in our industry; I countered that the collapse happened 
earlier, and Unix was the trigger. We weren't talking about the 
emergence of the web or the significance of Unix today.

Michael Kay
Saxonica

Alex Muir scripsit:

> Probably the only consistent selection across all tools would be for
> CamelCase.. underscore and minus would give different results across
> different tools.

Any tool that purports to support XML as such (as opposed to being a general
text editor) and doesn't know the rules for XML names, is either misconfigured
or buggy.

-- 
Let's face it: software is crap. Feature-laden and bloated, written under
tremendous time-pressure, often by incapable coders, using dangerous
languages and inadequate tools, trying to connect to heaps of broken or
obsolete protocols, implemented equally insufficiently, running on
unpredictable hardware -- we are all more than used to brokenness.
                   --Felix Winkelmann

I watch a room full of writers dedicating half their time and all of their
politics to creating a formatting art work out of which I am only going to
use their style names and keystrokes.  It's bewildering but I can cope. ;9

len

-----Original Message-----
From: Peter Flynn [mailto:peter@silmaril.ie] 
Sent: Saturday, February 04, 2012 3:19 PM
To: xml-dev@lists.xml.org
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication

On 02/02/12 23:22, Andrew Welch wrote:
>> but the results are that mediocrities become "best practices".
>
> Example please.

Microsoft Word?

///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

The key feature for web emergence was not the operating system.  It was the
combination of price, GUI and location on a consumer desk, ie, in a home
office and bedroom.  The rest was attitude.

len

-----Original Message-----
From: Peter Flynn [mailto:peter@silmaril.ie] 
Sent: Saturday, February 04, 2012 3:35 PM
To: xml-dev@lists.xml.org
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication

On 03/02/12 11:03, Pete Cordell wrote:
> Welcome to XML Celebrity Slamdown!
>
> I'm giving the contestants 1 point each.
>
> One to Michael for mentioning American purchasing systems. I'm amazed
> that very large American companies' purchasing systems still require you
> to enter a US State and a phone number in the North American numbering
> plan format. Lack of international awareness (or lack of international
> concerns) is not a 20 year-old historical artefact.

It's not really surprising, no matter how annoying it is. The US 
internal market is so large, and American SMEs (and some even bigger 
ones) do so well out of it, that they have no need for foreign clients. 
Not only do they not know where Europe is, but they actually don't give 
a damn anyway.

There are also the barriers erected to cross-Atlantic business by the US 
government *and* the EU authorities. US companies can't just ship goods 
out by taking a parcel to the post office and sticking a stamp on it. 
There are forms and rules and regulations designed to make it hard.

The well-known US multinationals do of course know all this, and happily 
sell abroad, often well-disguised by localisation, but they still make 
the same mistakes. Fortunately their forms are easy to fool.

> One to Len because I don't believe Unix would have got us to where we
> are today.

Unix as it was certainly never would have:fragmented, expensive, and 
laughably incompatible with everything except itself. And fat and 
self-centred and complacent: they never saw Linux coming.

///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

Not them, Peter.  Of course they're buggers.  

Us.  XML is a sweet bit of thinking that pays off regardless of how badly
they bugger all else.  XML doesn't care.

len

-----Original Message-----
From: Peter Flynn [mailto:peter@silmaril.ie] 
Sent: Saturday, February 04, 2012 3:40 PM
To: xml-dev@lists.xml.org
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication

On 03/02/12 17:30, cbullard@hiwaay.net wrote:
[...]
> 2) and back to the barn, it is critical that we keep our focus on open
> data resources for education, that is, remember why we do XML and what
> this extra effort to markup information buys us. If Apple can't get that
> into their products, then someone will and a few examples from what
> Texas does to school curricula will be enough to convince the smarter
> systems to buy NoTApple.

Sorry, Len. Not a chance. Politicos from school board level upwards to 
the White House can be -- and are being -- bought by companies, and will 
vote whatever way their paymasters tell them. Most of them don't appear 
to be very bright, either, and easily fall for the disinformation 
peddled by their corporate controllers, as we can and will see on both 
sides in the upcoming elections.

Happy days. "Stick with IBM, son, they'll look after you."

///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

Local trees?

len

-----Original Message-----
From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan
Sent: Saturday, February 04, 2012 3:58 PM

-- 
My confusion is rapidly waxing          John Cowan
For XML Schema's too taxing:            cowan@ccil.org
    I'd use DTDs                        http://www.ccil.org/~cowan
    If they had local trees --
I think I best switch to RELAX NG.

A power that be should hold a yearly contest for the simplest XML editor
that does useful work except Notepad.  Winner for ratio of useful work
performed over the least number of widgets.

len

-----Original Message-----
From: Peter Flynn [mailto:peter@silmaril.ie] 
Sent: Saturday, February 04, 2012 3:59 PM
To: xml-dev@lists.xml.org
Subject: Re:  Naming conventions for a sampling of W3C and ISO XML
vocabularies

On 04/02/12 00:09, Len Bullard wrote:
> All very good but how shall we choose?
>
> The virtue of XML is that with minimal coding skills and a handful of
> GUI, you can create tools that do useful work for you.

The virtue of XML is that with minimal coding skills and a handful of 
tools, you can create GUIs that do useful work for you.

///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

Alex Muir <alex.g.muir@gmail.com> a écrit :

>1 thing that cannot be cut and paste starting with 1 double click in an
>editor is no fun for me..
>
>Bad:
>condition-checks
>
>Good:
>condition_checks
>
>Best:
>conditionChecks
>
>from a clicking point of view

Choose a "programmer friendly" editor ;-) 
An editor that has no way to configure what characters defines a word is not a programmer's tool.
Even my terminal emulator(s) can do that. :-)

(You would love japanese and chinese: no separator between words :-P)

-- 
Envoyé de mon téléphone Android. Excusez la brièveté.

On 04/02/12 12:06, Alex Muir wrote:
> 1 thing that cannot be cut and paste starting with 1 double click in an
> editor is no fun for me..

You use wrong editor :-)

Simples!

///Peter

On 04/02/12 00:09, Len Bullard wrote:
> All very good but how shall we choose?
>
> The virtue of XML is that with minimal coding skills and a handful of
> GUI, you can create tools that do useful work for you.

The virtue of XML is that with minimal coding skills and a handful of 
tools, you can create GUIs that do useful work for you.

///Peter

On 03/02/12 14:48, Costello, Roger L. wrote:
> Hi Folks,
>
> I am sampling some standard XML vocabularies to see what naming
> convention they use. Below is what I've compiled thus far. What
> naming convention do you use?
>
> 1. XML Schema: all elements and attributes are camel case.

Written by people infected with the javaNamingVirus.

> 2. XSLT: all elements and attributes are lower-case, dash-separated.

Written by people immune to the javaNamingVirus.

> 3. Schematron: most elements and attributes are a single, lower-case word

Written by someone with a case-insensitive background :-)

///Peter

On 01/02/12 21:11, John Cowan wrote:
> Peter Flynn scripsit:
>
>> The OSI stuff was truly a nightmare to implement. An object lesson in
>> how not to construct a suite of protocols. Perhaps the sole legacies of
>> X.500 are the ghastly mess that is AD internals, and the use of the word
>> "distinguished" :-)
>
> Well, LDAP is hardly dead.

That I grant you, but I think that was designed for TCP/IP. I tried to 
implement a QUIPU X.500 directory once and gave up (and that was with 
personal tutelage from one of the authors).

///Peter

On 03/02/12 17:30, cbullard@hiwaay.net wrote:
[...]
> 2) and back to the barn, it is critical that we keep our focus on open
> data resources for education, that is, remember why we do XML and what
> this extra effort to markup information buys us. If Apple can't get that
> into their products, then someone will and a few examples from what
> Texas does to school curricula will be enough to convince the smarter
> systems to buy NoTApple.

Sorry, Len. Not a chance. Politicos from school board level upwards to 
the White House can be -- and are being -- bought by companies, and will 
vote whatever way their paymasters tell them. Most of them don't appear 
to be very bright, either, and easily fall for the disinformation 
peddled by their corporate controllers, as we can and will see on both 
sides in the upcoming elections.

Happy days. "Stick with IBM, son, they'll look after you."

///Peter

On 03/02/12 11:03, Pete Cordell wrote:
> Welcome to XML Celebrity Slamdown!
>
> I'm giving the contestants 1 point each.
>
> One to Michael for mentioning American purchasing systems. I'm amazed
> that very large American companies' purchasing systems still require you
> to enter a US State and a phone number in the North American numbering
> plan format. Lack of international awareness (or lack of international
> concerns) is not a 20 year-old historical artefact.

It's not really surprising, no matter how annoying it is. The US 
internal market is so large, and American SMEs (and some even bigger 
ones) do so well out of it, that they have no need for foreign clients. 
Not only do they not know where Europe is, but they actually don't give 
a damn anyway.

There are also the barriers erected to cross-Atlantic business by the US 
government *and* the EU authorities. US companies can't just ship goods 
out by taking a parcel to the post office and sticking a stamp on it. 
There are forms and rules and regulations designed to make it hard.

The well-known US multinationals do of course know all this, and happily 
sell abroad, often well-disguised by localisation, but they still make 
the same mistakes. Fortunately their forms are easy to fool.

> One to Len because I don't believe Unix would have got us to where we
> are today.

Unix as it was certainly never would have:fragmented, expensive, and 
laughably incompatible with everything except itself. And fat and 
self-centred and complacent: they never saw Linux coming.

///Peter

On 02/02/12 23:22, Andrew Welch wrote:
>> but the results are that mediocrities become "best practices".
>
> Example please.

Microsoft Word?

///Peter

Alex Muir scripsit:

> <test-test Some-Text="EWPB-Chinese_test_p54_1_warmup_1">
> <test_test  Some_Text="EWPB_Chinese_test_p54_1_warmup_1">

My terminal emulator, which is where I read mail, selects everything
between the quotes, unfortunately including the quotes too.

-- 
John Cowan        http://ccil.org/~cowan   cowan@ccil.org
Lope de Vega: "It wonders me I can speak at all.  Some caitiff rogue
did rudely yerk me on the knob, wherefrom my wits yet wander."
An Englishman: "Ay, belike a filchman to the nab'll leave you
crank for a spell." --Harry Turtledove, Ruled Britannia

Peter Flynn scripsit:

> Unix as it was certainly never would have:fragmented, expensive, and  
> laughably incompatible with everything except itself. And fat and  
> self-centred and complacent: they never saw Linux coming.

Modern BSDs are the Unixes that got it right (even if they've fragmented
as well); Linux is the Unix that succeeded.  As an old Unix weenie, I use
any or all of them (Solaris too), without worrying about fragmentation.
Right now, the Unix I use most is Cygwin.

-- 
My confusion is rapidly waxing          John Cowan
For XML Schema's too taxing:            cowan@ccil.org
    I'd use DTDs                        http://www.ccil.org/~cowan
    If they had local trees --
I think I best switch to RELAX NG.

Mike Sokolov scripsit:

> Should it be CamelCaseLol; not really - oughta be CamelCaseLOL I think.

Google's Java style guide goes with CamelCaseLol, even though the
Java libraries use CamelCaseLOL.  The trouble is with names like
RelativeURIFactory, where your eye can't see where the acronym ends
correctly.  RelativeUriFactory is more readable, even if you do have a
momentary flash of a canton in Switzerland.

ObXML: $EMPLOYER's NDRs, which I had a lot to do with (buffs nails),
use lowerCamelCaseLol for both elements and attributes.  We also control
spelling and hyphenation (hyphenated words are treated as two words)
by looking at m-w.com.


-- 
John Cowan                                   cowan@ccil.org
        "You need a change: try Canada"  "You need a change: try China"
                --fortune cookies opened by a couple that I know

Uche Ogbuji scripsit:

> The main problem I encounter with hyphens is in data binding to programming
> languages, but it boggles my mind to think that anyone would place the
> convenience of a programmer over the readability of the data. 

Oh yes, when the programming team is spending their budget on a schema
developer (which is how schema developers get paid at $EMPLOYER).
Uncle Mahmoud's first rule applies:  "The man that pays the bills,
keep him happy."

Not *too* happy, of course: it's important to be a professional
(a professional is someone who you hire to do what's right for you,
not just what you tell him), as well as to be seen as a professional
(otherwise some code monkey would wind up writing the schemas).

-- 
Verbogeny is one of the pleasurettes    John Cowan <cowan@ccil.org>
of a creatific thinkerizer.             http://www.ccil.org/~cowan
   --Peter da Silva

1. Insert all the embedded Schematron rules at the beginning of the RELAX NG schema as a child of the top-level element. Then you always know that if you have embedded rules, they will be specified together and in the same place.

2. Specify each Schematron rule on the element pattern that specifies the context of the embedded rule. In the previous example this means that one of the Schematron rules would be embedded on the element pattern for the item element and the other on the element pattern for the amount element in the payment section."

 >2. I will adopt the tag naming convention of one of the XML 
vocabularies that I will use. (Which one?)

Well, when XPath met XML Schema in XPath 2.0, we used both, and ended up 
with names like format-dateTime. Which at one level is totally logical, 
and at another level is just weird. There is no right answer.

Michael Kay
Saxonica

 >Soften it a little and consider IBM (I believe: Len? Michael?) who 
were building a precursor to what would eventually become the 
foundations of Latin-1. Right down somewhere near the bottom right-hand 
corner came the ÿ (yuml) character, which is used in French, and mostly 
in the names of some towns, but so rarely that even some French people 
are unaware of it, as I discovered when I asked some French LaTeX 
typesetters.

I believe that the main influence on ECMA-72 which became Latin-1 which 
became iso-8859-1 was actually DEC Multinational, developed for the 
vt220 terminal; though a couple of characters were substituted.

The way in which these decisions are made would be a fascinating study. 
I heard a tale that the IBM PC keyboard layout was dreamt up by a fairly 
junior engineer with no knowledge either of the years of effort to 
standardise keyboard layouts or of the extensive ergonomic and usability 
studies designed to maximize the performance of keyboard users. The 
resulting lost productivity must be costing us billions.

But then, someone has to decide. The Chinese, Japanese, and Koreans had 
been arguing for years about how to code ideographic characters, and in 
the end Xerox and a few Californian friends decided to tell them the 
answer. My friends in Japan told me they did such a bad job that it 
would never catch on, but they made the same mistake I have so often 
made myself - bad things do catch on.

Michael Kay
Saxonica

On Sat, 4 Feb 2012 14:01:44 +1100, Greg Hunt wrote:
> Do whatever balances consistency and existing local practice to minimise
> mental gear-changing.

Bravo!

Roger, the tools that you supply to [whoever] should be well-made, such 
that they neither cut the hand, nor deceive the eye (don't design a 
hammer that looks like a screwdriver; it may be funny, but it's just an 
annoyance on site).

Merging hyphen-delimited and camelCase?  You're pretty much screwed 
from the start.  For all *your* names, do hyphen-Camel, maybe, but 
expect people to cut themselves with hyphenCamel and deceive themselves 
with hyphen-camel.  If you're in a no-win situation, don't solicit bids 
for no-fail solutions.

As Greg points out: do what you can to make it "feel" consistent for 
users.  For instance: camelCase for new types vs. hyphen-delimited for 
new actions.  One *can* distinguish between XSLT and WXS in that way: 
schema defines "things", xslt defines "actions".  So, hyphenate your 
actions, camelize your things.

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
The one thing you can't trade for your heart's desire is your heart.
		-- Miles Vorkosigan

On 02/02/12 09:18, Michael Kay wrote:
[me]
>> A lot of this stuff was still relatively new, and only a few people
>> were thinking of non-European or non-Latin-alphabet languages.
>
> I don't think that's true. Vast numbers of people were thinking about
> them, but they weren't in California, and no-one in California took any
> notice.

You're right -- I phrased that badly. Only a few people _who were 
directly involved at the time_.

I can only speak to the areas I was involved in (HTML and XML) but the 
i18n push certainly appeared to be coming from a minority. I am told it 
was similar in other fields.

> Before the internet, the level of ignorance in the US about
> anything happening outside the US was staggering.

Still is, in places. As is the level of ignorance our side of the pond 
about things like the upcoming US presidential election :-)

///Peter

On 03/02/12 12:53, Tei wrote:
> He!...  mediocrity is not always bad.
>
> Say... databases.  Almost all web applications are built using
> relational databases.  Not all applications need a database. But web
> applications are soehorn to use relational databases anyway.

Tell me about it. I worked with some Oracle guys. They're really good, 
and seriously know their stuff, but ask them to add 2+2 and they'll 
define a table with two variables, write a screen to capture two values 
and stuff them into the table, then write a stored procedure to retrieve 
the values, add them, and format a report to print the result.

They are perfectly aware of other ways of doing this, and it's not as if 
they don't have access to tools other than hammers, but I have seen one 
of them populate a HTML select element of five options by pulling the 
data from a specially-written table, for data which won't change in my 
lifetime (Mr/Ms/Mrs/Miss/Dr).

So how do we extend this to the philosophical choices faced with XML, 
HTTP, or anything else? First off, it's scale. Hard-coding a web-form 
visitor's choice of title isn't a big deal, and if you need to add Rev, 
or if you get assimilated by the BBC and need to add Lord and Lady, 
that's not a big deal either; nor is it a big deal doing it in the 
database, modulo some small penalty in retrieval and dependency.

Convincing programmers to soft-code something large and mutable isn't 
hard either, like the set of ISO 3166 country codes, or the 639 language 
codes (or whatever the current suite is, I haven't looked at them for 
years). They can see the need for it, so the second clue is perception. 
We got 2-letter country TLDs when we could have used the 3-letter set 
and stayed the same length as .gov, .mil, .edu, .org, and .com. Doesn't 
matter a whole lot unless we end up with 26×26 nation states on the 
planet. But 2-letter language codes don't scale: there are way more than 
676 languages on this earth.

So eventually you get down to the third factor: judgement, which is 
based on knowledge and a shedload of other things. Programmer X speaks 
only Klingon, and doesn't really know much about other languages except 
for the existence of a few of them, high and far off; and certainly 
doesn't really care that anyone speaking Sindarin would ever have need 
to access the Internet, let alone in their own language. That's a harsh 
view, and mercifully rarer nowadays. Soften it a little and consider IBM 
(I believe: Len? Michael?) who were building a precursor to what would 
eventually become the foundations of Latin-1. Right down somewhere near 
the bottom right-hand corner came the ÿ (yuml) character, which is used 
in French, and mostly in the names of some towns, but so rarely that 
even some French people are unaware of it, as I discovered when I asked 
some French LaTeX typesetters. The ŵ character (wcirc), which is used 
daily by 3 million Welsh speakers didn't appear to get a look in until 
Latin-2.

So whats close to and up front tends to have more effect on what we 
decide -- when nothing else intervenes -- than what is high and far off. 
That's why it's good to have people who are able to take the longer 
view, with deeper knowledge, who can warn when things are likely to 
break if they don't take certain factors into account. They won't always 
be heeded, as Michael says, and we'll always be able to look back with 
regret on things we should have done differently, but I think it *is* 
improving a little: I see projects now which *do* take things into 
account that 20 years ago would (were) laughed out of the water.

So how much attention should we pay to charsets? It turns out, *lots*. 
But like my Oracle programmers, we have a bunch of knowledge on one 
side, and a bunch of tools on the other, and they all work, many even in 
the whole of Unicode, but we can't envisage the scale of demand for 
building that capability into every aspect of what we write, so we stick 
with what we know works. It's wrong, it will break, perhaps 
disastrously, and it will upset and affect lots of people, but right 
there and then it would have taken an order of magnitude longer to do it 
right.

Perhaps we can learn from history for once :-)

///Peter

Peter Flynn scripsit:

> So eventually you get down to the third factor: judgement, which is 
> based on knowledge and a shedload of other things.                  

"Good judgement is a matter of experience, and experience is a matter of
bad judgement."

> Soften it a little and consider IBM (I believe: Len? Michael?)
> who were building a precursor to what would eventually become
> the foundations of Latin-1. Right down somewhere near the bottom
> right-hand corner came the ÿ (yuml) character, which is used in
> French, and mostly in the names of some towns, but so rarely that even
> some French people are unaware of it, as I discovered when I asked
> some French LaTeX typesetters. The ŵ character (wcirc), which is used
> daily by 3 million Welsh speakers didn't appear to get a look in until
> Latin-2.

There's internal evidence that Latin-[1234] were designed together.
Specifically, if a character appears in more than one of these sets, it
always appears at the same code point.

> Perhaps we can learn from history for once :-)

"Papa Hegel he say that we learn from history that we learn nothing from
history.  *I* know people who can't learn from what happened last week."
--Chad C. Mulligan.

-- 
Henry S. Thompson said, / "Syntactic, structural,               John Cowan
Value constraints we / Express on the fly."                 cowan@ccil.org
Simon St. Laurent: "Your / Incomprehensible     http://www.ccil.org/~cowan
Abracadabralike / schemas must die!"

On Fri, 2012-02-03 at 14:48 +0000, Costello, Roger L. wrote:
> Hi Folks,
> 
> I am sampling some standard XML vocabularies to see what naming
> convention they use. Below is what I've compiled thus far. What naming
> convention do you use?
> 
> 1. XML Schema: all elements and attributes are camel case. Examples:
> maxOccurs, elementFormDefault, substitutionGroup.

This convention for XML names translate most easily into most non-XML
programming languages.
> 
> 2. XSLT: all elements and attributes are lower-case, dash-separated.
> Examples: apply-templates, exclude-result-prefixes, analyze-string.

If you do this, you need to have a data binding convention such as
mapping aaa-bbb to aaaBbbb or aaa_bbb.  This happens much more
frequently with Schema than with XSLT, so that may explain the
difference.  Of course, if you want to exchange arbitrary names between
XML and some other language, you're likely to need some sort of escaping
method or translation convention at some point, so camelCase just lets
you do a crappier initial data binding design :-)

No opinion here on Schematron.

I don't believe we (W3C) have a policy about name syntax.  The Dutch
parliament has a policy forbidding men from wearing white socks, but I
doubt it affects the quality of their legislation.

Liam

PS: some people in this discussion have confused some terms. XML admits
of only three different tag names: open, close, and empty. But you can
define your own element names and attribute names... it's worth being
clear about the distinction, not because of pedantry (despite mention of
socks) but because _tags_ are about the text-based interchange format of
XML, and elements are about the logical structure.  Understanding the
difference is part of the Nine-fold Path of Enlightagment in using XML
and XSLT.


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

> Here are two possibilities:
>
> 1. I will create a my own tag naming convention, independent of the XML vocabularies that I will use.
>
> 2. I will adopt the tag naming convention of one of the XML vocabularies that I will use. (Which one?)
>
> What do you recommend?


There is only one way :) names should be all lower-case, with hyphen
as a separator.  Camel case, or any thing else really, are awful for
xml.




-- 
Andrew Welch
http://andrewjwelch.com

> As Greg points out: do what you can to make it "feel" consistent for
> users.  For instance: camelCase for new types vs. hyphen-delimited for
> new actions.  One *can* distinguish between XSLT and WXS in that way:
> schema defines "things", xslt defines "actions".  So, hyphenate your
> actions, camelize your things.

better yet, caramelize your things.

Hi Folks,

I am about to create an XML vocabulary.

My XML vocabulary will leverage (reuse) three existing, mature XML vocabularies.

So my XML instances will consist of tags that I created and tags from the existing, mature XML vocabularies.

For the tags that I create, what tag naming convention should I use? 

Here are two possibilities:

1. I will create a my own tag naming convention, independent of the XML vocabularies that I will use.

2. I will adopt the tag naming convention of one of the XML vocabularies that I will use. (Which one?)

What do you recommend? 

What are the tradeoffs?

/Roger

>> Perhaps we can learn from history for once :-)
>
> "Papa Hegel he say that we learn from history that we learn nothing from
> history.  *I* know people who can't learn from what happened last week."
> --Chad C. Mulligan.

http://en.wikipedia.org/wiki/Learned_helplessness

On Fri, Feb 3, 2012 at 5:43 PM, Len Bullard <cbullard@hiwaay.net> wrote:
> The hyphen breaks visual flow.  The underscore delineates under the flow.
> But I only use them ‘n file names.  J


I completely disagree. Hyphens help the flow -- keeps the mind going
naturally to the next. Underscores drop you down - plunk - then you go
back up to return to the flow.

There ought to be a law.

-Rob

(btw, don't care, just joking)

>
>
>
> len
>
>
>
> -----Original Message-----
> From: David Lee [mailto:dlee@calldei.com]
> Sent: Friday, February 03, 2012 7:27 PM
> To: 'Uche Ogbuji'; xml-dev@lists.xml.org
> Subject: RE:  Should one adopt the tag naming convention of an
> existing XML vocabulary or create one's own tag naming convention?
>
>
>
> I Like My camelCase
>
> Besides its camelCase not "CamelCase"
>
> Maybe "camel-hypenCase_Under-scoreCase.is_BeTer"
>
> But do you prefix it with "_" or "s" or "m" if its a private, static, or
> member variable ?
>
> Thankfully Hungarian has lost its charm ...   I could never figure out what
> to do with an _pidwulshString variable when I changed it to simply char* ...
>
>
>
> I remember an interview with Stroustrup where he advocated under_score_case
> and thought camelCase was a bastard.   Those with opinions .. will they
> never stop pontificating !'
>
>
>
>
>
> I dont particularly like hyphen-case because I can't tell it apart from
> "hyphen" <minus> "case"
>
> even if the compiler can.
>
>
>
>
>
>
>
> ----------------------------------------
>
> David A. Lee
>
> dlee@calldei.com
>
> http://www.xmlsh.org
>
>
>
> From: Uche Ogbuji [mailto:uche@ogbuji.net]
> Sent: Friday, February 03, 2012 3:18 PM
> To: xml-dev@lists.xml.org
> Subject: Re:  Should one adopt the tag naming convention of an
> existing XML vocabulary or create one's own tag naming convention?
>
>
>
> On Fri, Feb 3, 2012 at 1:11 PM, Andrew Welch <andrew.j.welch@gmail.com>
> wrote:
>
>> Here are two possibilities:
>>
>> 1. I will create a my own tag naming convention, independent of the XML
>> vocabularies that I will use.
>>
>> 2. I will adopt the tag naming convention of one of the XML vocabularies
>> that I will use. (Which one?)
>>
>> What do you recommend?
>
>
> There is only one way :) names should be all lower-case, with hyphen
> as a separator.  Camel case, or any thing else really, are awful for
> xml.
>
>
>
> I strongly agree, but of course this one is a very subjective matter. I
> curse Java for its propagation of the CamelCase eyesore.
>
>
>
> --
> Uche Ogbuji                       http://uche.ogbuji.net
> Weblog: http://copia.ogbuji.net
> Poetry ed @TNB: http://www.thenervousbreakdown.com/author/uogbuji/
> Founding Partner, Zepheira        http://zepheira.com
> Linked-in: http://www.linkedin.com/in/ucheogbuji
> Articles: http://uche.ogbuji.net/tech/publications/
> Friendfeed: http://friendfeed.com/uche
> Twitter: http://twitter.com/uogbuji
> http://www.google.com/profiles/uche.ogbuji

" I have always found context and end users to be the driving force, 
when a "standard" DTD was not available."

Yes.  Given a local set of practices in layout, you can extract enough
information from the style name and text to build back up to richly tagged
information.  Again, the virtue of XML is what can be usefully done with a
handful of GUI and free code.  A fellow published the DocToXML code on a
site and it gave a good way to get a basic task done.  Take it as a starting
point and build to it.  Did that.  Easy.  Cheap.  Works.

I've been using this method and it works given basic XML utilities.  Do it
all on the desktop.  When at this chore, ignore the web. 

Let the browser be the browser.

len

-----Original Message-----
From: W. Hugh Chatfield [mailto:csi2000@urbanmarket.com] 
Sent: Friday, February 03, 2012 2:28 PM
To: xml-dev@lists.xml.org; Costello, Roger L.
Subject: Re:  Should one adopt the tag naming convention of
anexisting XMLvocabulary or create one's own tag naming convention?

What I know from my past projects is that the naming conventions depend 
a lot on what you are trying to model with the DTD, and the end users 
of your model.  (assuming DTD here - but could be schemas, etc. 
 these project were from way back). 

For example, the CALS DTD.  THe US CALS DTD was basically a model of 
the "documents" being produced.  In other words, they used text 
concepts like volume, chapter, section, para, table, etc. 

When I worked on the CALS DTD for Canada it was decided the DTD would 
be a model of "equipment" not "documents" - hence there were tags 
 introduced for concepts like assembly (recursive) and for each 
assembly there were parts list, trouble shooting tables, equipment 
description, repair instructions, etc.  Sure ultimately, when the 
content wound up as "text", it made sense to use textual tags - 
section, para, etc. - and there we could have adopted common tag names 
- but even these would have specific equipment tags in the mixed 
content sections.  Tables weren't columns and rows, they were 
symptoms, test procedure, repair procedure, etc. - but were still 
rendered as a table. 

When working with the Department of Justice - it was decide to use tag 
names that the authors of legislative text (lawyers and legal 
specialists) already understood and were in use from authoring all the 
way through parliament.  This was before any generic legislative DTDs 
hit the market.  We tried to minimize the disruption in the authoring 
process on the switch from a highly customized older version of 
Word-Perfect to SGML. 

So I have always found context and end users to be the driving force, 
when a "standard" DTD was not available.  Maybe if you are trying to 
decide a tag name from 3 different vocabularies, you would pick the one 
with the greatest degree of fit to your end user... whatever degree of 
fit might mean in your environment. 

Cheers....Hugh

UBL is in your future....  http://goUBL.com

On Fri, 3 Feb 2012 19:14:24 +0000, "Costello, Roger L." 
<costello@mitre.org> wrote:
Hi Folks,
>
> I am about to create an XML vocabulary. 
>
> My XML vocabulary will leverage (reuse) three existing, mature XML 
> vocabularies. 
>
> So my XML instances will consist of tags that I created and tags from 
> the existing, mature XML vocabularies. 
>
> For the tags that I create, what tag naming convention should I use? 
> Here are two possibilities:
>
> 1. I will create a my own tag naming convention, independent of the 
> XML vocabularies that I will use. 
>
> 2. I will adopt the tag naming convention of one of the XML 
> vocabularies that I will use. (Which one?)
>
> What do you recommend? What are the tradeoffs?
>
> /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

True.

On the other hand, there are long lived lists such as this that can work on
learning.  Always has.  A digital blessing but a real goal of most of the
people I've met that are real XML hackers.  Nature of the technology:  human
negotiated, hardware implemented, hardware independent.  The requirements
for the system determine the makeup of the community that builds it.  Guilds
are ecosystem constructs.

IME, guilds best nations where innovation is the objective.  The humans are
at their best when they self-select.

len

-----Original Message-----
From: Peter Flynn [mailto:peter@silmaril.ie] 
Sent: Friday, February 03, 2012 4:26 PM
To: xml-dev@lists.xml.org
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication


> Before the internet, the level of ignorance in the US about
> anything happening outside the US was staggering.

Still is, in places. As is the level of ignorance our side of the pond 
about things like the upcoming US presidential election :-)

///Peter

Which is how the IADS designers with a prototype of the features of XML AND
markup style sheets with a validation and built in editor (a not
well-explored design, really) felt about Mosaic and the SGML community felt
about IADS (didn't require a DTD: wasn't SGML de facto).

Dems da breaks.   Both systems do useful work as in the users can produce
the deliverables in the CDRLs with a low rate of defects returned for budget
hours consumed.

Mediocre systems service insecure managers.   Simple systems that just work
service any user.

len

-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com] 
Sent: Friday, February 03, 2012 4:59 PM
To: xml-dev@lists.xml.org
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication

 > but they made the same mistake I have so often 
made myself - bad things do catch on.

Michael Kay
Saxonica

Original Message From: <cbullard@hiwaay.net>
> From my perspective, this was inevitable and  what I meant over the years 
> of watching the sea changes since the web  and muttering "welcome to the 
> music industry".  Selling digital  anything has a common core of 
> opportunities for this kind of  consolidation and controlling the entry of 
> new resources.

In interesting way to look at it.  (I nearly said analogy, but it's closer 
to reality than that!)

What really scars me is Apple's iBooks for schools.  A brilliant concept if 
it were open, but highly disturbing if one company controls what a nation's 
children are taught.

(But I think I've now moved out of the barnyard!)

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: "John Cowan"
> Pete Cordell scripsit:
>
>> It was the American hobbyists that won, as exemplified by Gates
>> and Jobs.
>
> Not "exemplified by".  "Sold to by", maybe.  Or "sold out by".


Happy is a man that turns his hobby into a business.  Especially if he 
becomes a multi-billionaire!

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

 >Notice that Schematron isn't consistent in its naming convention. Is 
that a bad thing?

Yes.

 >Is it a good thing to have a consistent naming convention?

Yes.

 >Why does XML Schema and XSLT have different naming conventions?

My guess would be that it's due to ignorance (I didn't know they were 
doing that), but it could be arrogance (Those guys don't know what 
they're doing, and/or Who cares what X is doing, no-one will ever use X 
anyway). Those are only guesses. Untangling the history is rarely possible.

 >They are both W3C technologies. Does the W3C not have a policy on 
naming markup?

It probably does by now, it has on most things. But it certainly didn't 
have in the days when you could get a spec out in 6 months. Which might 
not be a coincidence.

Michael Kay
Saxonica

What I know from my past projects is that the naming conventions depend
a lot on what you are trying to model with the DTD, and the end users
of your model.  (assuming DTD here - but could be schemas, etc.
 these project were from way back).

For example, the CALS DTD.  THe US CALS DTD was basically a model of
the "documents" being produced.  In other words, they used text
concepts like volume, chapter, section, para, table, etc.

When I worked on the CALS DTD for Canada it was decided the DTD would
be a model of "equipment" not "documents" - hence there were tags
 introduced for concepts like assembly (recursive) and for each
assembly there were parts list, trouble shooting tables, equipment
description, repair instructions, etc.  Sure ultimately, when the
content wound up as "text", it made sense to use textual tags -
section, para, etc. - and there we could have adopted common tag names
- but even these would have specific equipment tags in the mixed
content sections.  Tables weren't columns and rows, they were
symptoms, test procedure, repair procedure, etc. - but were still
rendered as a table.

When working with the Department of Justice - it was decide to use tag
names that the authors of legislative text (lawyers and legal
specialists) already understood and were in use from authoring all the
way through parliament.  This was before any generic legislative DTDs
hit the market.  We tried to minimize the disruption in the authoring
process on the switch from a highly customized older version of
Word-Perfect to SGML.

So I have always found context and end users to be the driving force,
when a "standard" DTD was not available.  Maybe if you are trying to
decide a tag name from 3 different vocabularies, you would pick the one
with the greatest degree of fit to your end user... whatever degree of
fit might mean in your environment.

Cheers....Hugh

UBL is in your future....  http://goUBL.com

On Fri, 3 Feb 2012 19:14:24 +0000, "Costello, Roger L."
<costello@mitre.org> wrote:
Hi Folks,
>
> I am about to create an XML vocabulary.
>
> My XML vocabulary will leverage (reuse) three existing, mature XML
> vocabularies.
>
> So my XML instances will consist of tags that I created and tags from
> the existing, mature XML vocabularies.
>
> For the tags that I create, what tag naming convention should I use?
> Here are two possibilities:
>
> 1. I will create a my own tag naming convention, independent of the
> XML vocabularies that I will use.
>
> 2. I will adopt the tag naming convention of one of the XML
> vocabularies that I will use. (Which one?)
>
> What do you recommend? What are the tradeoffs?
>
> /Roger
>  

Hi Folks,

I am sampling some standard XML vocabularies to see what naming convention they use. Below is what I've compiled thus far. What naming convention do you use?

1. XML Schema: all elements and attributes are camel case. Examples: maxOccurs, elementFormDefault, substitutionGroup.

2. XSLT: all elements and attributes are lower-case, dash-separated. Examples: apply-templates, exclude-result-prefixes, analyze-string.

3. Schematron: most elements and attributes are a single, lower-case word (e.g., assert, rule, pattern). There is an element and an attribute with multiple words (value-of, is-a). There are two elements that use camel case (queryBinding and defaultPhase).

Notice that Schematron isn't consistent in its naming convention. Is that a bad thing? Is it a good thing to have a consistent naming convention?

Why does XML Schema and XSLT have different naming conventions? They are both W3C technologies. Does the W3C not have a policy on naming markup?

/Roger

Now the DTDs are huge polyglots that mix the two concepts of content  
and structural naming.  The rear tabular matter is mostly content  
named.  The front matter (eg, maintenance procedures, theory of ops)  
tend to be all structural names (chapter, volume, etc.).  The CALS  
tables are still in there but there are fewer of them.  It's an  
interesting panoply of every approach we've tried.

A more interesting question asked before and answered by folks like  
Eliot Kimber is when one should use XML type ids and idrefs.  I used  
to say there was no cost to having an id so go ahead, but that isn't  
really true and I was wrong.  A #REQUIRED ID is... required and when  
one has to manually scrub a large file, these little bits of cruft  
become odious.

len

Quoting "W. Hugh Chatfield" <csi2000@urbanmarket.com>:

> What I know from my past projects is that the naming conventions  
> depend a lot on what you are trying to model with the DTD, and the  
> end users of your model.  (assuming DTD here - but could be schemas,  
> etc.  these project were from way back). For example, the CALS DTD.  
>  THe US CALS DTD was basically a model of the "documents" being  
> produced.  In other words, they used text concepts like volume,  
> chapter, section, para, table, etc. When I worked on the CALS DTD  
> for Canada it was decided the DTD would be a model of "equipment"  
> not "documents" - hence there were tags  introduced for concepts  
> like assembly (recursive) and for each assembly there were parts  
> list, trouble shooting tables, equipment description, repair  
> instructions, etc.  Sure ultimately, when the content wound up as  
> "text", it made sense to use textual tags - section, para, etc. -  
> and there we could have adopted common tag names - but even these  
> would have specific equipment tags in the mixed content sections.  
>  Tables weren't columns and rows, they were symptoms, test  
> procedure, repair procedure, etc. - but were still rendered as a  
> table. When working with the Department of Justice - it was decide  
> to use tag names that the authors of legislative text (lawyers and  
> legal specialists) already understood and were in use from authoring  
> all the way through parliament.  This was before any generic  
> legislative DTDs hit the market.  We tried to minimize the  
> disruption in the authoring process on the switch from a highly  
> customized older version of Word-Perfect to SGML. So I have always  
> found context and end users to be the driving force, when a  
> "standard" DTD was not available.  Maybe if you are trying to decide  
> a tag name from 3 different vocabularies, you would pick the one  
> with the greatest degree of fit to your end user... whatever degree  
> of fit might mean in your environment. Cheers....Hugh
>
> UBL is in your future....  http://goUBL.com
>
> On Fri, 3 Feb 2012 19:14:24 +0000, "Costello, Roger L."  
> <costello@mitre.org> wrote:
> Hi Folks,
>>
>> I am about to create an XML vocabulary. My XML vocabulary will  
>> leverage (reuse) three existing, mature XML vocabularies. So my XML  
>> instances will consist of tags that I created and tags from the  
>> existing, mature XML vocabularies. For the tags that I create, what  
>> tag naming convention should I use? Here are two possibilities:
>>
>> 1. I will create a my own tag naming convention, independent of the  
>> XML vocabularies that I will use. 2. I will adopt the tag naming  
>> convention of one of the XML vocabularies that I will use. (Which  
>> one?)
>>
>> What do you recommend? What are the tradeoffs?
>>
>> /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
>
>
>

Purely selfishly, I use the underscore (nods to Andrew) if I plan to  
use the name in microparsing.  Spaces are unreliable (people don't  
notice double spaces, single quotes disappear to aging eyes,  
underscores when doubled are human-eye noticeable.  A split function  
using an underscore is easy to see in the code that does the  
microparsing.

That said, I tend to camel_Case XML as a typing habit.  I would hazard  
a guess that camel_Case is a side effect of scanning lots of tags by  
eye and needing to sort out the sub-names inside the case.  I think  
that easier.  For the machine, someone else has to make the case for  
the Case.  I'm not sure it's useful in that regard.

In the system I'm working today, the locals giggled at the underscores  
in the file names claiming they were so "old school" and that "spaces  
are modern".  I let them have back the 3000+ files with an extra space  
in one of the file names.

Here's one for you, Roger:  do you think file names should preserve  
the names of the systems tracking the system in line before them or  
rename for the system the follows?  IOW, do we push names forward or  
track them backward?  I have my own story but I'd like to hear what  
you think?  As with granularity, there are practical reasons for  
choosing.

len

Quoting "Costello, Roger L." <costello@mitre.org>:

> Hi Folks,
>
> I am sampling some standard XML vocabularies to see what naming  
> convention they use. Below is what I've compiled thus far. What  
> naming convention do you use?
>
> 1. XML Schema: all elements and attributes are camel case. Examples:  
> maxOccurs, elementFormDefault, substitutionGroup.
>
> 2. XSLT: all elements and attributes are lower-case, dash-separated.  
> Examples: apply-templates, exclude-result-prefixes, analyze-string.
>
> 3. Schematron: most elements and attributes are a single, lower-case  
> word (e.g., assert, rule, pattern). There is an element and an  
> attribute with multiple words (value-of, is-a). There are two  
> elements that use camel case (queryBinding and defaultPhase).
>
> Notice that Schematron isn't consistent in its naming convention. Is  
> that a bad thing? Is it a good thing to have a consistent naming  
> convention?
>
> Why does XML Schema and XSLT have different naming conventions? They  
> are both W3C technologies. Does the W3C not have a policy on naming  
> markup?
>
> /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
>
>
>

Alex Muir scripsit:

> Well the other thing I'm not clear on is that for the RNG the schematron
> logic can be placed after the top level grammar element,, for the RNC I'm
> getting syntax error

I don't understand that.  An element placed after the document (top-level)
element would not be well-formed XML.

-- 
John Cowan    cowan@ccil.org    http://ccil.org/~cowan
Objective consideration of contemporary phenomena compel the conclusion
that optimum or inadequate performance in the trend of competitive
activities exhibits no tendency to be commensurate with innate capacity,
but that a considerable element of the unpredictable must invariably be
taken into account. --Ecclesiastes 9:11, Orwell/Brown version

He!...  mediocrity is not always bad.

Say... databases.  Almost all web applications are built using
relational databases.  Not all applications need a database. But web
applications are soehorn to use relational databases anyway.  Some of
the applications that are implemented using databases (perhaps most
CMS's) would run better and be more flexible using a document
database, like MongoDB.   What we win using databases for everything?
economy of scale,  people become very good at producing relational
database-based software,  make very few mistakes because made a lot of
experience with that stuff.

The average person can do a good job with mediocre tools, but If you
give the average person a tool that is "too clever", the probability
of a bad output is high than 50%.   Give the average programmer
something like Ruby or Perl,  and hope for the best!, but it will
result on some shitty code, because Ruby and Perl are clever
programming languages, not for the average joe.

So the average webmaster is going to use <div> in a non semantic way
(=crappy).  But will break less thing doing that than with "abbr
article aside audio bdi canvas data datalist details figcaption figure
footer header hgroup mark".  The average webmaster has no idea how to
use properly  "figcaption" or "aside".




On 3 February 2012 01:07, Len Bullard <cbullard@hiwaay.net> wrote:
> <div>
>
> len
>
> -----Original Message-----
> From: Andrew Welch [mailto:andrew.j.welch@gmail.com]
>
>> but the results are that mediocrities become "best practices".
>
> Example please.
>
>
>
> _______________________________________________________________________
>
> 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
>



-- 
--
ℱin del ℳensaje.

Alex Muir scripsit:

> with trang I get this lovely concoction,,

Trang doesn't know what your annotations mean, so it carefully preserves
all whitespace, both horizontal and vertical.  You can edit that out
either on the RNG or the RNC side, as you please.

-- 
Henry S. Thompson said, / "Syntactic, structural,               John Cowan
Value constraints we / Express on the fly."                 cowan@ccil.org
Simon St. Laurent: "Your / Incomprehensible     http://www.ccil.org/~cowan
Abracadabralike / schemas must die!"

We debated that on Jon Taplin's blog given his iPad and Anything Apple  
enthrallment.  Money really shines for some abnd unfortunately, some  
of them are educators by title.

Two points: 1)  American educational materials are already captured by  
the fact that few publishers supply that market and they are thralls  
of the Texas School Boards which are their biggest market and very  
conservative.  Enuff said.

2)  and back to the barn, it is critical that we keep our focus on  
open data resources for education, that is, remember why we do XML and  
what this extra effort to markup information buys us.  If Apple can't  
get that into their products, then someone will and a few examples  
from what Texas does to school curricula will be enough to convince  
the smarter systems to buy NoTApple.

As for those who don't, to put words into the mouth of the Great Gazoo:

"Let evolution succeed.  Let the dum dums die."

len


Quoting Pete Cordell <petexmldev@codalogic.com>:

> Original Message From: <cbullard@hiwaay.net>
>> From my perspective, this was inevitable and  what I meant over the  
>> years of watching the sea changes since the web  and muttering  
>> "welcome to the music industry".  Selling digital  anything has a  
>> common core of opportunities for this kind of  consolidation and  
>> controlling the entry of new resources.
>
> In interesting way to look at it.  (I nearly said analogy, but it's  
> closer to reality than that!)
>
> What really scars me is Apple's iBooks for schools.  A brilliant  
> concept if it were open, but highly disturbing if one company  
> controls what a nation's children are taught.
>
> (But I think I've now moved out of the barnyard!)
>
> 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
>
>

Dim memories are that a) Bosak argued for camel case and it was trendy  
at the time.  b) Don't remember but XSLT inherited from DSSSL work and  
that may be where that originates.  Check with James Clark.  c)   
Schematron is originally Rick Jeliffe's fine work.  He may have some  
insights.

Yes, naming conventions are useful but where work has different  
original sources and then get grandfathered it can be arduous to  
rework them and otherwise, it isn't the top priority in the insanely  
political and still technically complex work of spec baking.

As Michael hints at, time to approval is an issue.  The W3C was to be  
the ISO-replacement because it could get a spec done fast when doing  
things in "Internet Time" was trendy.   The results of that are mixed.  
  To come up to true international quality (world-class), processes  
have to slow down for QA and multiple implementations.  The claim that  
they will be overcome by events is overblown now that actual  
infrastructure development is mostly done for the current phase of web  
evolution.

We say we can clean up later.  Mostly we don't because any technology  
that is widely successful and fielded is hard to get out of the  
stickiness of deployment.  In this, the web has multiple meanings.

len


Quoting "Costello, Roger L." <costello@mitre.org>:

> Hi Folks,
>
> I am sampling some standard XML vocabularies to see what naming  
> convention they use. Below is what I've compiled thus far. What  
> naming convention do you use?
>
> 1. XML Schema: all elements and attributes are camel case. Examples:  
> maxOccurs, elementFormDefault, substitutionGroup.
>
> 2. XSLT: all elements and attributes are lower-case, dash-separated.  
> Examples: apply-templates, exclude-result-prefixes, analyze-string.
>
> 3. Schematron: most elements and attributes are a single, lower-case  
> word (e.g., assert, rule, pattern). There is an element and an  
> attribute with multiple words (value-of, is-a). There are two  
> elements that use camel case (queryBinding and defaultPhase).
>
> Notice that Schematron isn't consistent in its naming convention. Is  
> that a bad thing? Is it a good thing to have a consistent naming  
> convention?
>
> Why does XML Schema and XSLT have different naming conventions? They  
> are both W3C technologies. Does the W3C not have a policy on naming  
> markup?
>
> /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
>
>
>

Pete Cordell scripsit:

> It was the American hobbyists that won, as exemplified by Gates
> and Jobs.

Not "exemplified by".  "Sold to by", maybe.  Or "sold out by".

-- 
Kill Gorgun!  Kill orc-folk!            John Cowan
No other words please Wild Men.         cowan@ccil.org
Drive away bad air and darkness         http://www.ccil.org/~cowan
with bright iron!   --Ghan-buri-Ghan    http://www.ccil.org/~cowan

On Fri, Feb 3, 2012 at 10:38 AM, Michael Kay <mike@saxonica.com> wrote:
> On 02/02/2012 22:16, cbullard@hiwaay.net wrote:
>>
>> Things changed because the market changed.  In the 1980s the markets for
>> software in Europe were to put it mildly, soft in comparison to the domestic
>> markets.
>
> I assume domestic should be read as "American" here?

its not like the UK helps itself by constantly defining itself in
terms of the special relationship is has with the US ... <flamebait>UK
is kind of like a domestic market for the US</flamebait>

> And I'm not sure what you mean by "soft". Less competitive? Less profitable?
> Smaller? Certainly in many areas of software, it's very hard to penetrate
> overseas markets because you need such a deep knowledge of local
> requirements, and that's true whether you're exporting from the US to Europe

living in the Czech Republic reminds me of how Europe used to be e.g.
much of the government software procurement is a locked up cabal ...
government entities across Europe were very closed and getting into
these markets was next to impossible. Most of Eastern Europe is still
privatising these institutions and getting their tendering procedures
more open ... these kind of activities takes decades to work out.

Also lets face it, doing business in Europe is difficult ... most
countries treat entrepreneurs terribly ... if Saxonica was in the
states you would get all lot more opportunity and benefits and more
chance for things like investment (which probably may not float your
boat, unsure).

> or vice versa. (Just look at the form I'm trying to complete for a current
> US government procurement, which demands to know stuff about my policy on
> employing disabled Vietnam-war veterans, and whether the University that I
> attended was "historically black". Some of the questions are so invasive I'm
> not allowed to answer them under UK privacy law).

sure, the odd thing about irrelevant questions like this is less about
the data they gather and analysis they will do on it (I don't put so
much faith in governments ability to do IT) but the sheer uselessness
of the activity ... btw this kind of 'jumping through hoops' activity
beats whatever happens in communist countries hands down (my wife
reminds me of the inanity of communist rules and I am certain most of
us would have been crushed by them).

as for the reasons why you get asked such questions ... I would try to
remind myself that these kind of laws were passed with a sense of
doing right in the world, well meaning but poorly executed.

invoking the UK privacy law as if its better is a bit of a red
herring, most of the UK privacy laws protect celebrities and
rich/ennobled folk and cost money to gain the benefit of ... its just
like in the states e.g. money talks.

>>
>> It took the consolidation of a lot of different companies around Microsoft
>> products to change the vertical stacks into horizontal ones.
>
> Actually, in Europe it was Unix that caused that change, not Microsoft. The
> trend (X/Open in particular) was in full swing in the early 1980s, long
> before Microsoft was a force to be reckoned with. The rise of the
> independent database companies (Oracle, Ingres, Informix) had nothing to do
> with Microsoft.

in Europe like anywhere if its free, this will get used first ...
especially new democracies.

>>  No one plays what's mine is mine and what's your's is mine as well as
>> Apple plays it and others such as Amazon and Facebook are shuttering the web
>> blinds to plays from companies that rely on openness such as Google even as
>> some free ride on Google openness and sharing in technologies such as
>> Android.
>>
> Yes, the ebb and flow between open and closed is fascinating to watch;
> depressing at times, but certainly interesting. Particularly depressing is
> that the regulators seem to be about 10 years behind, still fighting the
> browser wars. The way they are allowing Apple and Amazon to tie content to
> hardware amazes me: I thought that had all been made illegal 20 years ago.
>
> Not that I find the Google business model - pay for everything through
> advertising, and collect as much private data as you can in order to target
> the advertising - particularly appealing either.

Open Source continues to prove itself best for innovation (as well as
promoting sanity with developers) and I would say have a bit more
faith, the open source model is crawling the domain space for a
superior business model ... it eventually will discover something
better then 'advertising'.

Jim Fuller

Alex Muir scripsit:

> Hi so a quick google search of
> 
> Embed schematron rules "relax-NC" -- 4 results none of any value
> verses
> Embed schematron rules "relax-NG" -- answer how to do it comes up
> 
> tells me that I'm only going to be able to Embed schematron rules
> "relax-NG" which is logical enough given the XML

Dr. Google, while informative, doesn't know everything.  If you read
http://relaxng.org/compact-tutorial-20030326.html#annotations , you
will find out how to embed arbitrary XML (which includes Schematron)
into RELAX NG compact syntax.  Basically, the syntax is to wrap each
XML element in square brackets.  The first thing in the square bracket
is the element name, anything that follows that looks like an attribute
is an attribute, and character data has to be quoted.

Also, .rnc format is normally called "RELAX NG compact syntax", not
"RELAX-NC".

So a Schematron rule like

   <sch:pattern>
      <sch:title>Date rules</sch:title>
      <sch:rule context="Contract">
         <sch:assert test="ContractDate &lt; current-date()">ContractDate should be in the past because future contracts are not allowed.</sch:assert>
      </sch:rule>
   </sch:pattern>

becomes

[sch:pattern
  [sch:title "Date rules"]
  [sch:rule context="Contract"
    [sch:assert test="ContractDate < current-date()"
      "ContractDate should be in the past because future contracts are not allowed."]]]

Clunky, but usable.  Trang understands this syntax when converting from
RNG to RNC and vice versa.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
To say that Bilbo's breath was taken away is no description at all.  There are
no words left to express his staggerment, since Men changed the language that
they learned of elves in the days when all the world was wonderful. --The Hobbit

Welcome to XML Celebrity Slamdown!

I'm giving the contestants 1 point each.

One to Michael for mentioning American purchasing systems.  I'm amazed that 
very large American companies' purchasing systems still require you to enter 
a US State and a phone number in the North American numbering plan format. 
Lack of international awareness (or lack of international concerns) is not a 
20 year-old historical artefact.

One to Len because I don't believe Unix would have got us to where we are 
today.  Really, neither the European computer industry won, nor the American 
computer industry won.  It was the American hobbyists that won, as 
exemplified by Gates and Jobs.  Europe's focus was largely on satisfying the 
needs of large corporations.  If you wanted a computer you had the choice of 
one that required its own air conditioned room and only did payroll, or one 
that you could put in a corner and also played Pacman!  With hindsight, no 
contest!

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: "Michael Kay" <mike@saxonica.com>
To: <cbullard@hiwaay.net>
Cc: <xml-dev@lists.xml.org>
Sent: Friday, February 03, 2012 9:38 AM
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication


> On 02/02/2012 22:16, cbullard@hiwaay.net wrote:
>> Things changed because the market changed.  In the 1980s the markets for 
>> software in Europe were to put it mildly, soft in comparison to the 
>> domestic markets.
> I assume domestic should be read as "American" here?
>
> And I'm not sure what you mean by "soft". Less competitive? Less 
> profitable? Smaller? Certainly in many areas of software, it's very hard 
> to penetrate overseas markets because you need such a deep knowledge of 
> local requirements, and that's true whether you're exporting from the US 
> to Europe or vice versa. (Just look at the form I'm trying to complete for 
> a current US government procurement, which demands to know stuff about my 
> policy on employing disabled Vietnam-war veterans, and whether the 
> University that I attended was "historically black". Some of the questions 
> are so invasive I'm not allowed to answer them under UK privacy law).
>>
>>
>> It took the consolidation of a lot of different companies around 
>> Microsoft products to change the vertical stacks into horizontal ones.
> Actually, in Europe it was Unix that caused that change, not Microsoft. 
> The trend (X/Open in particular) was in full swing in the early 1980s, 
> long before Microsoft was a force to be reckoned with. The rise of the 
> independent database companies (Oracle, Ingres, Informix) had nothing to 
> do with Microsoft.
>>   No one plays what's mine is mine and what's your's is mine as well as 
>> Apple plays it and others such as Amazon and Facebook are shuttering the 
>> web blinds to plays from companies that rely on openness such as Google 
>> even as some free ride on Google openness and sharing in technologies 
>> such as Android.
>>
> Yes, the ebb and flow between open and closed is fascinating to watch; 
> depressing at times, but certainly interesting. Particularly depressing is 
> that the regulators seem to be about 10 years behind, still fighting the 
> browser wars. The way they are allowing Apple and Amazon to tie content to 
> hardware amazes me: I thought that had all been made illegal 20 years ago.
>
> Not that I find the Google business model - pay for everything through 
> advertising, and collect as much private data as you can in order to 
> target the advertising - particularly appealing either.
>
> 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
> 

Political power is implicit in markup technologies because they 
redistribute control of publication. It's wonderful to read these 
messages that touch on the political effect of the technology, though I 
appreciate that this is a deservedly rare deviation from the intent of 
the list.

What a sterile conversation this would have been had we all been 
restricted by purely commercial interest.

John Adam Turnbull

Andrew Welch scripsit:

> Fwiw, it's not just that, there is the business apps side:
> 
> http://www.google.com/apps/intl/en/business/index.html
> 
> ...and don't forget Android licensing and Market app sale commissions,
> and then there's Wallet transaction fees etc

All trivial by comparison to the ad-placement business.

-- 
John Cowan          http://www.ccil.org/~cowan         cowan@ccil.org
The native charset of SMS messages supports English, French, mainland
Scandinavian languages, German, Italian, Spanish with no accents, and
GREEK SHOUTING.  Everything else has to be Unicode, which means you get
only 70 16-bit characters in a text instead of 160 7-bit characters.

> Not that I find the Google business model - pay for everything through
> advertising, and collect as much private data as you can in order to target
> the advertising - particularly appealing either.

Fwiw, it's not just that, there is the business apps side:

http://www.google.com/apps/intl/en/business/index.html

...and don't forget Android licensing and Market app sale commissions,
and then there's Wallet transaction fees etc




-- 
Andrew Welch
http://andrewjwelch.com

On 02/02/2012 22:16, cbullard@hiwaay.net wrote:
> Things changed because the market changed.  In the 1980s the markets 
> for software in Europe were to put it mildly, soft in comparison to 
> the domestic markets.
I assume domestic should be read as "American" here?

And I'm not sure what you mean by "soft". Less competitive? Less 
profitable? Smaller? Certainly in many areas of software, it's very hard 
to penetrate overseas markets because you need such a deep knowledge of 
local requirements, and that's true whether you're exporting from the US 
to Europe or vice versa. (Just look at the form I'm trying to complete 
for a current US government procurement, which demands to know stuff 
about my policy on employing disabled Vietnam-war veterans, and whether 
the University that I attended was "historically black". Some of the 
questions are so invasive I'm not allowed to answer them under UK 
privacy law).
>
>
> It took the consolidation of a lot of different companies around 
> Microsoft products to change the vertical stacks into horizontal ones.
Actually, in Europe it was Unix that caused that change, not Microsoft. 
The trend (X/Open in particular) was in full swing in the early 1980s, 
long before Microsoft was a force to be reckoned with. The rise of the 
independent database companies (Oracle, Ingres, Informix) had nothing to 
do with Microsoft.
>   No one plays what's mine is mine and what's your's is mine as well 
> as Apple plays it and others such as Amazon and Facebook are 
> shuttering the web blinds to plays from companies that rely on 
> openness such as Google even as some free ride on Google openness and 
> sharing in technologies such as Android.
>
Yes, the ebb and flow between open and closed is fascinating to watch; 
depressing at times, but certainly interesting. Particularly depressing 
is that the regulators seem to be about 10 years behind, still fighting 
the browser wars. The way they are allowing Apple and Amazon to tie 
content to hardware amazes me: I thought that had all been made illegal 
20 years ago.

Not that I find the Google business model - pay for everything through 
advertising, and collect as much private data as you can in order to 
target the advertising - particularly appealing either.

Michael Kay
Saxonica

It takes a long time but is rooted in the card shark vs holy scroller  
debates held here and elsewhere some (now many) years ago.  The frame  
guys took a real beating only to see <div> show up.  <div> proved that  
neither side had much of a claim.  An addressable chunk is an  
addressable chunk.

As Tei said, mediocrity isn't always bad.  That's why I think of it as  
averaging.  Consensus won't always produce a superior solution.  It  
produces a solution people are willing to use and if like me, you see  
technical evolution as a breeding process, not a competition for who  
is the smartest person in the room, use is the best measure of  
success, therefore, 'practice'.

Among musicians there is a saying: the difference between a rock  
musician and a jazz musician is a rock musician plays three chords for  
thousands of people and a jazz musician plays a thousand chords for  
three people.  Mediocrity has a place and the difference is how many  
and which albums will you keep when the significant other packs it in  
and you have to split the community property.

len

Quoting Andrew Welch <andrew.j.welch@gmail.com>:

> :) You will need to explain that one for me...
>
> On 3 February 2012 00:07, Len Bullard <cbullard@hiwaay.net> wrote:
>> <div>
>>
>> len
>>
>> -----Original Message-----
>> From: Andrew Welch [mailto:andrew.j.welch@gmail.com]
>>
>>> but the results are that mediocrities become "best practices".
>>
>> Example please.
>>
>>
>
>
>
> --
> 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
>
>

Sorry for going off the reservation, Pete.

One thing that is not mediocre:  the consistent quality of  
well-informed, erudite and well-debated conversation on XML-Dev.    
 From the heart, this list continues to be an inspiration in just how  
well international conversation succeeds when held by high-minded  
talented people.  Neither Facebook nor Google or any of the tiny box  
to type in social network sites can achieve what mail lists such as  
this one have with the extended threads, complete posts, and  
occasional runs past the barnyard gate.  As long as that is so, I  
don't fear for the web.

len

Quoting Pete Cordell <petexmldev@codalogic.com>:

> Welcome to XML Celebrity Slamdown!
>
> I'm giving the contestants 1 point each.
>
> One to Michael for mentioning American purchasing systems.  I'm  
> amazed that very large American companies' purchasing systems still  
> require you to enter a US State and a phone number in the North  
> American numbering plan format. Lack of international awareness (or  
> lack of international concerns) is not a 20 year-old historical  
> artefact.
>
> One to Len because I don't believe Unix would have got us to where  
> we are today.  Really, neither the European computer industry won,  
> nor the American computer industry won.  It was the American  
> hobbyists that won, as exemplified by Gates and Jobs.  Europe's  
> focus was largely on satisfying the needs of large corporations.  If  
> you wanted a computer you had the choice of one that required its  
> own air conditioned room and only did payroll, or one that you could  
> put in a corner and also played Pacman!  With hindsight, no contest!
>
> 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: "Michael Kay" <mike@saxonica.com>
> To: <cbullard@hiwaay.net>
> Cc: <xml-dev@lists.xml.org>
> Sent: Friday, February 03, 2012 9:38 AM
> Subject: Re:  RE: Encoding charset of HTTP Basic Authentication
>
>
>> On 02/02/2012 22:16, cbullard@hiwaay.net wrote:
>>> Things changed because the market changed.  In the 1980s the  
>>> markets for software in Europe were to put it mildly, soft in  
>>> comparison to the domestic markets.
>> I assume domestic should be read as "American" here?
>>
>> And I'm not sure what you mean by "soft". Less competitive? Less  
>> profitable? Smaller? Certainly in many areas of software, it's very  
>> hard to penetrate overseas markets because you need such a deep  
>> knowledge of local requirements, and that's true whether you're  
>> exporting from the US to Europe or vice versa. (Just look at the  
>> form I'm trying to complete for a current US government  
>> procurement, which demands to know stuff about my policy on  
>> employing disabled Vietnam-war veterans, and whether the University  
>> that I attended was "historically black". Some of the questions are  
>> so invasive I'm not allowed to answer them under UK privacy law).
>>>
>>>
>>> It took the consolidation of a lot of different companies around  
>>> Microsoft products to change the vertical stacks into horizontal  
>>> ones.
>> Actually, in Europe it was Unix that caused that change, not  
>> Microsoft. The trend (X/Open in particular) was in full swing in  
>> the early 1980s, long before Microsoft was a force to be reckoned  
>> with. The rise of the independent database companies (Oracle,  
>> Ingres, Informix) had nothing to do with Microsoft.
>>>  No one plays what's mine is mine and what's your's is mine as  
>>> well as Apple plays it and others such as Amazon and Facebook are  
>>> shuttering the web blinds to plays from companies that rely on  
>>> openness such as Google even as some free ride on Google openness  
>>> and sharing in technologies such as Android.
>>>
>> Yes, the ebb and flow between open and closed is fascinating to  
>> watch; depressing at times, but certainly interesting. Particularly  
>> depressing is that the regulators seem to be about 10 years behind,  
>> still fighting the browser wars. The way they are allowing Apple  
>> and Amazon to tie content to hardware amazes me: I thought that had  
>> all been made illegal 20 years ago.
>>
>> Not that I find the Google business model - pay for everything  
>> through advertising, and collect as much private data as you can in  
>> order to target the advertising - particularly appealing either.
>>
>> 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
>>
>
>
> _______________________________________________________________________
>
> 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
>
>

Quoting Michael Kay <mike@saxonica.com>:

> On 02/02/2012 22:16, cbullard@hiwaay.net wrote:
> I assume domestic should be read as "American" here?

Context matters.

> And I'm not sure what you mean by "soft". Less competitive? Less profitable?

Smaller and less profitable.  It's a matter of what is needed to sell  
into a market and is that as lucrative short term as other  
opportunities.  A significant change was the fall of the Wall.  At GE  
I talked about what was needed to put SGML into the newly-non  
Communist bloc countries.  Joan Smith's reply to me was "But, Len,  
they have no money."  As we discover, globalization is not a single  
issue.

> Smaller? Certainly in many areas of software, it's very hard to  
> penetrate overseas markets because you need such a deep knowledge of  
> local requirements, and that's true whether you're exporting from  
> the US to Europe or vice versa. (Just look at the form I'm trying to  
> complete for a current US government procurement, which demands to  
> know stuff about my policy on employing disabled Vietnam-war  
> veterans, and whether the University that I attended was  
> "historically black". Some of the questions are so invasive I'm not  
> allowed to answer them under UK privacy law).

True and getting worse.  We overregulate and I say that as a  
"progressive".  There is some truth to the "nation of the offended"  
but we aren't unique in that.  As for their policy, tell them that you  
employ a half dozen Vietnamese in Ho Chi Mihn city.  They'll like  
that.  As for the other, tell them you attended the University of  
Dublin.

Every culture has it's sins.  There is a time for remediation then  
there is a time to move on.

>> It took the consolidation of a lot of different companies around  
>> Microsoft products to change the vertical stacks into horizontal  
>> ones.
> Actually, in Europe it was Unix that caused that change, not Microsoft.

We did the Unix phase too right after VMS.   What I am referring to is  
the penetration of the desktop into the home market.  Until that  
happened, global hypermedia was a lot of lab experiments in a lot of  
labs around the world and the Internet was a bulletin board with  
email.  Microsoft made it possible to have a non-laughable web.

>>  No one plays what's mine is mine and what's your's is mine as well  
>> as Apple plays it and others such as Amazon and Facebook are  
>> shuttering the web blinds to plays from companies that rely on  
>> openness such as Google even as some free ride on Google openness  
>> and sharing in technologies such as Android.
>>
> Yes, the ebb and flow between open and closed is fascinating to  
> watch; depressing at times, but certainly interesting. Particularly  
> depressing is that the regulators seem to be about 10 years behind,  
> still fighting the browser wars. The way they are allowing Apple and  
> Amazon to tie content to hardware amazes me: I thought that had all  
> been made illegal 20 years ago.

I thought we had posse commitatus and habeas corpus forever.  Then  
they signed those away too.  Very depressing.  I think anyone who  
can't see the class struggle at hand is blind but that's not a good  
topic for this forum. Just my own frustration...  Meanwhile Neil Young  
is lamenting the death of Steve Jobs because Apple is no longer  
pursuring high fidelity downloads.  The American music industry in  
particular has been eager to make any deal that will return power of  
that market to the small cadres that had it and the computer science  
industry is eager to make those deals to get exclusive distributions  
and half the profits.  From my perspective, this was inevitable and  
what I meant over the years of watching the sea changes since the web  
and muttering "welcome to the music industry".  Selling digital  
anything has a common core of opportunities for this kind of  
consolidation and controlling the entry of new resources.   Again,  
YouTube is the indie's best friend and YouTube is the radio.  That is  
where Neil Young doesn't get it.

> Not that I find the Google business model - pay for everything  
> through advertising, and collect as much private data as you can in  
> order to target the advertising - particularly appealing either.

If they were invading privacy, I would agree but it seems we are all  
willing to give that up to get to the free services and toys.   
Predictable but not a popular sentiment.  As I said a long time ago,  
we are forging our own chains.  To be fair, I am a real user of  
YouTube for finding works and for publishing my own and the 'free'  
part of that makes a difference.   The trends worry me because they  
tend to be like a nuclear arms race:  if one does it, there is a rush  
for all the near neighbors.   Apple has set a stunning example and I  
expect others to follow unless someone can prove why that's a bad idea.

Anyway, I'm way way off topic.  Apologies to the list.

len

:) You will need to explain that one for me...

On 3 February 2012 00:07, Len Bullard <cbullard@hiwaay.net> wrote:
> <div>
>
> len
>
> -----Original Message-----
> From: Andrew Welch [mailto:andrew.j.welch@gmail.com]
>
>> but the results are that mediocrities become "best practices".
>
> Example please.
>
>



-- 
Andrew Welch
http://andrewjwelch.com

> but the results are that mediocrities become "best practices".

Example please.




-- 
Andrew Welch
http://andrewjwelch.com

Guy standing by the road watching the history of GUIs marching off into the
sunset like tired sloths looks at the guy next to him and mutters, "I hate
the GUI migration.  Pack up the kids.  We're moving again."

len

-----Original Message-----
From: Andrew Welch [mailto:andrew.j.welch@gmail.com] 
Sent: Thursday, February 02, 2012 5:22 PM
To: cbullard@hiwaay.net
Cc: Petite Abeille; xml-dev
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication

> but the results are that mediocrities become "best practices".

Example please.

<div>

len

-----Original Message-----
From: Andrew Welch [mailto:andrew.j.welch@gmail.com] 

> but the results are that mediocrities become "best practices".

Example please.

On Feb 2, 2012, at 4:12 PM, Michael Kay wrote:

> the relentless industry pursuit of mediocracy

In polite circles, mediocrity is known as "best practices":

http://dilbert.com/strips/comic/2008-09-03/

Or simply average.  Welcome to the music business.

When a market such as the web inculcates wants what will work for the  
average joe, mediocrity, or average, is the almost certain outcome.   
Does this have to be the case?  Unfortunately, yes.  Almost every big  
change in the comp-sci market as long as I can remember came about  
because someone sat down to "simplify" or "dumb down" an existing  
pervasive or soon to be pervasive aspect of that market.  The choices  
made in that process may be brilliant, but the results are that  
mediocrities become "best practices".

len

Quoting Petite Abeille <petite.abeille@gmail.com>:

>
> On Feb 2, 2012, at 4:12 PM, Michael Kay wrote:
>
>> the relentless industry pursuit of mediocracy
>
> In polite circles, mediocrity is known as "best practices":
>
> http://dilbert.com/strips/comic/2008-09-03/
>
>
> _______________________________________________________________________
>
> 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
>
>

Things changed because the market changed.  In the 1980s the markets  
for software in Europe were to put it mildly, soft in comparison to  
the domestic markets.  On the other hand, as someone who was working  
in a company that sold to the Middle East and Europe at that time we  
certainly were aware of internationalization as well as the other  
problems of the smaller markets such as the intense tribalism that  
forced us to hunt through every document we shipped for any drawing  
that suggested a Star of David, mentioned Israel, etc.  For all the  
good ideas, the problems of European markets are also there.

It took the consolidation of a lot of different companies around  
Microsoft products to change the vertical stacks into horizontal ones.  
  The web was the next impetus but overall, until a truely integrated  
international market existed, there were few compelling market  
arguments for it.  The work follows the money.  Sad but so.

The Chinese cooperation with efforts such as X3D are notable.  They do  
tend to look for the bits being ignored over here and figure out ways  
to profit by them, and interesting habit for a Communist country, and  
smart.

<aside>The Americans aren't unaware.  We tend to regard all markets as  
profit centers and leave the social work to social workers.  For all  
the talk in the last twenty years about openness, the most profitable  
businesses in this industry are a) American and b) closed.   No one  
plays what's mine is mine and what's your's is mine as well as Apple  
plays it and others such as Amazon and Facebook are shuttering the web  
blinds to plays from companies that rely on openness such as Google  
even as some free ride on Google openness and sharing in technologies  
such as Android.

I believe the change from cooperation to close and capture has come to  
the web overall.  How this will play out in standards and  
specifications is pretty easy to guess.  It is going to get  
increasingly harder for the innovators despite all political speech to  
the contrary.  This is a good time for the young ones among us to  
think long and hard about their ambitions and values given that so  
much of what they have been taught about the web philosophies while  
right in spirit are increasingly unviable in practice.  The bad old  
days are coming back, Michael.  Just one opinion...</aside>

len

Quoting Michael Kay <mike@saxonica.com>:

> On 02/02/2012 14:45, cbullard@hiwaay.net wrote:
>> Not just a little Euro-centric jealousy there, Michael?
>>
> More frustration than jealousy, at all the good work that has come  
> to naught over the years, and all the people who didn't get the  
> recognition they deserved. But I guess that European designers  
> aren't the only ones whose ideas have been ignored in the relentless  
> industry pursuit of mediocracy. All one can say is, things are far  
> better today than they used to be around the 1980s - at least for  
> Europeans; there's still a woeful ignorance in the West of all the  
> interesting things happening in Japan and China, because they read  
> our language and we don't read theirs (plus they know the value of  
> listening, lurking, and learning).
>
> 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
>
>

Catching up on the list after a prolonged distraction, I see no one has replied to your query. As a newcomer to XML myself, I can recommend the following--not because they're perfect, but merely because they helped me come up to my present speed (which, granted, isn't at all dizzying--but it's enabling me to function in a setting in which I have to interact with XML etc. just frequently enough to mean I need to know it, and just infrequently enough to make it hard to remember):

(Step 1) Study in tandem:

* Kevin Howard Goldberg, XML (2nd ed.) -- in the Visual Quickstart Guide series, which I detest, but this one worked for me
* Simon St. Laurent & Michael Fitzgerald, XML Pocket Reference (3rd. Edition)

(Step 2) If your interests lie anywhere in the direction of EITHER of the technologies mentioned in its title, then buy a copy of this one, study the introductory bits (throughout), and keep it by your side at all times:

* Michael Kay, XSLT 2.0 and XPath 2.0 Programmer's Reference (4th ed.) -- Wrox

(Meanwhile) 

* Follow this mailing list and the XSL list (at mulberrytech.com). Much of the discussion will be over your head, but you will learn all manner of fascinating bits and pieces along the way--and most important, you'll get a feel for the real XML world. (The books, for example, might lead you to wonder why anyone in his right mind would write XML Schema for anything. The lists will tell you that no one does unless forced to by some fairly compelling and unusual set of circumstances.)

* I also follow the schematron and relax ng lists, but they're not very active. I can't tell if that's because hardly anyone uses those technologies, or because those who do don't have many questions.

Warning: The preceding recommendations are based on a sample size of one, which should not be considered representative.

Norm Birkett

> -----Original Message-----
> From: Bob Jolliffe [mailto:bobjolliffe@gmail.com]
> Sent: Wednesday, January 04, 2012 4:02 AM
> To: xml-dev@lists.xml.org
> Subject:  book for beginners
> 
> Does anyone have any book recommendations for a beginner student which
> covers the *fundamentals* of xml validation and processing?  Bearing
> in mind I guess that people would have different ideas of what is
> fundamental.  I would think a good overview should touch upon DTDs,
> W3C Xml Schema, RelaxNg, Schematron, NVDL, Xpath, Xslt, Xquery, XProc.
>  Maybe this list is too long.  Maybe it is missing something vital.
> Would be nice also to include something on the different homes and
> genesis of these things - W3C, OASIS, ISO - that students understand
> that specifications are not found in nature ...
> 
> Thanks
> Bob
> 
> _______________________________________________________________________
> 
> 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 02/02/2012 14:45, cbullard@hiwaay.net wrote:
> Not just a little Euro-centric jealousy there, Michael?
>
More frustration than jealousy, at all the good work that has come to 
naught over the years, and all the people who didn't get the recognition 
they deserved. But I guess that European designers aren't the only ones 
whose ideas have been ignored in the relentless industry pursuit of 
mediocracy. All one can say is, things are far better today than they 
used to be around the 1980s - at least for Europeans; there's still a 
woeful ignorance in the West of all the interesting things happening in 
Japan and China, because they read our language and we don't read theirs 
(plus they know the value of listening, lurking, and learning).

Michael Kay
Saxonica

> Fair enough. FWIW, my personal experience is the exact opposite: pointless, bloated, big design up-front, busy work which never gets anything done. But as always, YMMV.
>
I would say, putting a lot of design effort up front into creating a 
really elegant and compact foundation that will prove highly extensible 
is effort well spent. Putting a lot of effort up front into implementing 
all the features that anyone might ever want is effort wasted.

Michael Kay
Saxonica

 >A lot of this stuff was still relatively new, and only a few people 
were thinking of non-European or non-Latin-alphabet languages.

I don't think that's true. Vast numbers of people were thinking about 
them, but they weren't in California, and no-one in California took any 
notice. Before the internet, the level of ignorance in the US about 
anything happening outside the US was staggering. The amazing thing is 
that HTTP/HTML ever made it across from Switzerland.

(Just consider: why did Microsoft, for many years, refer to Latin-1 as 
"ANSI"? Answer: because that's what it said on the cover of the copy 
that they acquired. ISO standards in those days were published in the US 
with an ANSI rebranding. Microsoft were not only ignorant that it was an 
international standard rather than an American one, they were also 
clearly unaware that there were zillions of other ANSI standards.)

Michael Kay
Saxonica

On Feb 2, 2012, at 5:11 AM, Michael Sokolov wrote:

> You have to estimate the likelihood of future change later and compare against the cost of wasted effort now.  

Not only wasted effort (one-off), but also the tax of added complexity (recurrent, exponential).  Not to mention ongoing maintenance of unwarranted code.

Tangentially related quote of the day:

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” 
—JOHN GALL

Not just a little Euro-centric jealousy there, Michael?

If TimBL had prevailed, we'd be arguing about a modified RTF.

len

Quoting Michael Kay <mike@saxonica.com>:

> Before the internet, the level of ignorance in the US about anything  
> happening outside the US was staggering. The amazing thing is that  
> HTTP/HTML ever made it across from Switzerland.

Contemplating the work before me, it may be advantageous to strip a  
DTD down to a set of DTDs each of which do something specific (thus  
the earlier thread about granularity).  The problem of version creep  
is it leads to a polyglot that is difficult to manage in code say in  
the GUI controls where it better be a very simple set of options or  
the user gets lost and codes the wrong elements.

There likely was a technology shift of focus between versions because  
having coded to the most recent and now rolling back one, it is  
apparent in the prior version someone(s) was trying to use database  
concepts and didn't quite make it across the chasm from structured  
chapters to tables and rows.  In the new version, the elements in the  
databasey parts of the document (reference matter) look more like  
objects and property sets (someone realized not every row in a  
document table really is a row in a database needing an id.  Still, we  
have to id every one of them (#REQUIRED) despite the fact that no  
IDREF points to them or ever will.  Upshot:  we pay the cost (or are  
paid for it) until the very slow migration to the newer version is  
reasonably complete while keeping all the code supporting the last  
version because.. you never know.

It will most often come back to incomplete knowledge, Boltzmann's revenge.

Possibly a different topic:  how to factor the least used parts of a  
language into their own boxes so those that do can and those that  
don't do don't have to know how.

len

Scope Creep: often heard in the bathroom gargling before spending the  
morning hassling his co-workers.

Quoting Peter Flynn <peter@silmaril.ie>:

> I have lost count of the projects whose first task was to strip all  
> namespaces and cut the XSD down to a DTD representing only the  
> element types that were actually used. In only a few cases have I  
> been able to persuade them to do the modelling in RNG and recreate a  
> minimally workable Schema. But this is solid text-document XML, with  
> more character data content than markup :-)
>
> ///Peter

Variations depend on where you are in the stack AND the locale.  For  
example, if I started with that assumption, nothing I am writing would  
be of much use to the community in which I am situated which is  
squarely in the DTD camp and bloody big complex ones with multiple  
associated versions.  A mild bad surprise yesterday was to have  
converted a large RPSTL to a tag set only to open the DTD of note and  
find a different tag set:  same information, but different tags and  
different id'd elements.  Version creep.

Another variant is the stack:  are you writing XML software or are you  
using XML software to create an application (e.g., are you writing a  
parser or creating your own color-coded rich text box or are you  
dragging them into the forms, googling the API/docs and implementing a  
search and replace and a set of canned queries)?  Starting over has  
different costs.  In the latter case, throwing things at the wall for  
awhile until you are comfortable with the operations (eg, does it  
surprise you and do things you didn't plan for but realized you need  
only to find out it does that) isn't that bad.  Not checking the DTD  
first and completely understanding it? Not good but recoverable.  Not  
being told the customer switched to XML Schemas a week ago?  A bad day  
in hell.

Nimbleness is awareness and preparation.  Few get it right the first  
time and depending on the task at hand, no two developments start in  
the same place.  If you make assumptions based on "the larger XML  
community" then you are saying they are your customer or your  
supplier.  If you do that and they aren't one or the other, you're  
screwing up.

I'm building tools because I need them to do a specific job set.  YMMV  
and mine is a different job than writing for a market to which you  
haven't sold anything or which you propose to create.  On the other  
hand, if you are immersed in a particular market and what you create  
is saving you time and money, increasing quality and reducing misery,  
there is a better than even chance it will do the same for others in  
the same community.

Keep a copy of code that works even if you decide not to use it.  You  
never know.

len

Quoting John Cowan <cowan@mercury.ccil.org>:

> Costello, Roger L. scripsit:
>
>> In the case of the discussion at hand, the assumption is what? Is it
>> the following? Assumption: The larger XML community will always use
>> XML Schema so just create data models using XML Schema.
>
> Something like that.

On 1 February 2012 22:26, John Cowan <cowan@mercury.ccil.org> wrote:
> Petite Abeille scripsit:
>
>> Fair enough. FWIW, my personal experience is the exact opposite:
>> pointless, bloated, big design up-front, busy work which never gets
>> anything done. But as always, YMMV.
>
> Believe me, I've had plenty of experience of that.  If you truly aren't
> going to need something, YAGNI is a huge win.  But there's no reason to
> pretend that just because this is only the first report you are writing,
> that there won't be hundreds more reports.

I think the theory goes, you use all of the good practice and patterns
you know while you are coding something, but don't add in unnecessary
flexibility up-front... as then it's a cost that you've definitely
incurred regardless, as more often than not the project gets cancelled
or the world moves on before that flexibility pays back the cost.

I think (again, sorry its all vague) that's from Agile, maybe someone
will know either way.



-- 
Andrew Welch
http://andrewjwelch.com

Michael Sokolov scripsit:

> Or said another way, let's say we believe the 10/100 rule above. What is  
> the likelihood that project X will be adopted in another locale than the  
> one for which it was originally designed?  If it's less than 10%, you  
> shouldn't bother with i18n up front.

If you really know that (as when it is bespoke software) then yes.  The
trouble is that "prediction is very difficult, especially about the future"
(attr. Niels Bohr).  There is also the problem of barriers to entry:
localizing a non-i18n program may be so hard that commercial opportunities
are surrendered needlessly.

-- 
MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS
John Cowan      cowan@ccil.org      http://www.ccil.org/~cowan

On Feb 1, 2012, at 10:55 PM, John Cowan wrote:

> Change is not free.  XP advocates claim that if the rest of their
> methods are followed, it costs no more to make a change later than to
> make it now; my view of this claim is that "all theory is for it, but
> all experience is against it."

Fair enough. FWIW, my personal experience is the exact opposite: pointless, bloated, big design up-front, busy work which never gets anything done. But as always, YMMV.

On 2/1/2012 3:45 PM, John Cowan wrote:
> Andrew Welch scripsit:
>
>> One approach is: do nothing. Incur that cost if and when it's actually
>> needed, don't waste your time/effort/money on it now.
> I have never cared for this idea, and indeed there are many obvious
> counterexamples.  Tim Bray's stuff on internationalization (back
> when it was a new and radical idea) showed that the cost of i18n at
> development time is about 10%, whereas after the fact it's about 100%.
I don't think there's a hard-and-fast rule.  You have to estimate the 
likelihood of future change later and compare against the cost of wasted 
effort now.  I do think our estimates of the former are much more 
error-prone though.

If you knew for sure which thing you were absolutely going to have to 
deal with eventually, you should certainly plan for it now.  The problem 
is when you don't know.  Then there will be many things (maybe 10!) that 
you could decide to build in abstractions for now.  But perhaps only one 
of them will be needed.

Or said another way, let's say we believe the 10/100 rule above. What is 
the likelihood that project X will be adopted in another locale than the 
one for which it was originally designed?  If it's less than 10%, you 
shouldn't bother with i18n up front.
-Mike

On Feb 1, 2012, at 9:45 PM, John Cowan wrote:

> it is always simplest
> to hard-code all assumptions, but it *will* force redesign further
> down the line, and the more assumptions, the more redesign.

And what's wrong with redesign? After all, we are dealing with software, which, by its very nature, is infinitely malleable.

Hi Roger,
   Nice examples.

Here are possibly two more approaches that may be possible for this
use case (these are XSD 1.1 specific). Both of these use the wild-card
element to specify variable nature of the content, and restricting the
content possibilities via assertion.

a)

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

     <xs:element name="suitcase">
	    <xs:complexType>
		   <xs:sequence>
		         <xs:any minOccurs="3" maxOccurs="3"/>
		   </xs:sequence>
		   <xs:assert test="deep-equal(*/name(),
('shorts','Hawaiian-shirts','sunglasses'))
		                                or
					    deep-equal(*/name(), ('dress-shirt','tie','jacket'))"/>
		</xs:complexType>
	 </xs:element>
	
	 <xs:element name="shorts" type="xs:string" />

	 <xs:element name="Hawaiian-shirts" type="xs:string" />

	 <xs:element name="sunglasses" type="xs:string" />

	 <xs:element name="dress-shirt" type="xs:string" />

	 <xs:element name="tie" type="xs:string" />

	 <xs:element name="jacket" type="xs:string" />
			
</xs:schema>

pros about this approach: since the wild-card in this case has
specifier processContents="strict", therefore the XML instance
structure validated by the wild-card is strongly typed.

cons about this approach: to use the "strict" wild-card, the element
declarations that validate the XML instance elements that need to be
validated by the wild-card need to be global element declarations.
This has side effect of passing validation of the top-most XML
instance elements that are validated by these *wild-card provider*
element declarations.

b)

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

     <xs:element name="suitcase">
	    <xs:complexType>
		 <xs:sequence>
		      <xs:any minOccurs="3" maxOccurs="3" processContents="skip"/>
		 </xs:sequence>
		 <xs:assert test="not(*/*)"/>
		 <xs:assert test="deep-equal(*/name(),('shorts','Hawaiian-shirts','sunglasses'))
		                              or
					  deep-equal(*/name(),('dress-shirt','tie','jacket'))"/>
	   </xs:complexType>
     </xs:element>
			
</xs:schema>

pros of this approach: this is a shorter schema than the first one
(possible due to the wild-card "skip" mode) and it doesn't suffer from
the cons of the first approach.

cons of this approach: the wild-card relies entirely on the assertions
to constraint (i.e to enforce some kind of typing) XML instance
structure that is validated by it. for this trivial case the <assert>
in this example does this correctly & completely (the first assert
enforces simple content for corresponding instance elements), but to
constrain deep XML fragments via <assert> may be hard (i.e simulating
a generic complexType).

Needless to mention: there may be various ways to solve a problem :)

On Tue, Jan 31, 2012 at 6:34 PM, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
>
>
> Consider the problem of designing an XML Schema for a suitcase that has
> different content depending on the travel purpose. For example, if going on
> a vacation then the content of suitcase is shorts, Hawaiian shirts, and
> sunglasses; if going on a business trip then the content of suitcase is
> dress-shirt, tie, and jacket.
>
> The suitcase has varying content. The suitcase is called a variable content
> container.
>
> The XML Schema Best Practice for variable content containers describes four
> methods for creating variable content containers:
>
> Use an abstract element and element substitution
> Use a <choice> element
> Use an abstract type and type substitution
> Use a dangling type
>
> http://www.xfront.com/VariableContentContainers.html
>
> This message describes a fifth method. It uses a schema’s context to provide
> content for its variable content container.
>
> Method 5: Implementing variable content containers using context schemas
>
> The following XML Schema document -- vacation.xsd --  includes suitcase.xsd:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>            targetNamespace="http://www.trip.org/vacation"
>            elementFormDefault="qualified">
>
>     <xs:include schemaLocation="suitcase.xsd" />
>
>     <xs:complexType name="clothes">
>         <xs:sequence>
>             <xs:element name="shorts" type="xs:string" />
>             <xs:element name="Hawaiian-shirts" type="xs:string" />
>             <xs:element name="sunglasses" type="xs:string" />
>         </xs:sequence>
>     </xs:complexType>
>
> </xs:schema>
>
> Here is a second schema document -- business-trip.xsd -- that also includes
> suitcase.xsd:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>            targetNamespace="http://www.trip.org/business-trip"
>            elementFormDefault="qualified">
>
>     <xs:include schemaLocation="suitcase.xsd" />
>
>     <xs:complexType name="clothes">
>         <xs:sequence>
>             <xs:element name="dress-shirt" type="xs:string" />
>             <xs:element name="tie" type="xs:string" />
>             <xs:element name="jacket" type="xs:string" />
>         </xs:sequence>
>     </xs:complexType>
>
> </xs:schema>
>
> Both vacation.xsd and business-trip.xsd are context for suitcase.xsd. Both
> have a different namespace. Both define a complexType, clothes.
>
> Now let’s examine suitcase.xsd. It is a no-namespace schema document. It
> declares a suitcase element and depends on context for filling in its
> content (for providing a definition of “clothes”):
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
>
>     <xs:element name="suitcase" type="clothes" />
>
> </xs:schema>
>
> If the context schema document is vacation.xsd then the content of suitcase
> is shorts, Hawaiian shirts, and sunglasses. If the context schema document
> is business-trip.xsd then the content of suitcase is dress-shirt, tie, and
> jacket.
>
> Also notice that due to the Chameleon Effect the suitcase element is
> namespace-coerced to the namespaces http://www.trip.org/vacation and
> http://www.trip.org/business-trip, respectively.
>
> This example illustrates a context-dependent data model -- the suitcase
> element depends on its context (environment) schemas to complete its content
> model.
>
> Assessment
>
> Method 5 is similar to method 4 (dangling types) but with one important
> difference: with method 4 the schema used to specify the content of the
> variable content container is specified in the XML instance document whereas
> with method 5 the schema used to specify the content of the variable content
> container is specified in the content schema. Thus, method 4 is a run-time
> association whereas method 5 is a compile-time association. That may be an
> important difference for your situation.
>
> As with all engineering approaches, there are advantages and disadvantages.
> Let’s list them for method 5.
>
> Advantages
>
> -          Dynamic: A schema which depends on its context is dynamic. It
> does not statically hard-code the identity of a schema item to implement the
> content. Rather, it empowers schema developers that use a context schema to
> identify content.
>
> -          Applicable to any Schema Item: The context schema is not limited
> to only complexTypes. It can provide elements, attributes, simpleTypes,
> complexTypes, in fact, any schema item. Thus, this method is useful for more
> than just variable content containers.
>
> Disadvantages
>
> -          Context-Dependent Validation: A schema which depends on its
> context cannot be validated in isolation. It can only be validated in
> combination with its context schemas.
>
> FAQ
>
> Question: suitcase.xsd isn’t valid because type=”clothes” hasn’t been
> defined, right?
>
> You are correct. When taken independent of context suitcase.xsd is invalid.
> Suitcase.xsd depends on a context schema for validity. Thus, don’t validate
> suitcase.xsd. Instead, validate vacation.xsd or business-trip.xsd.
>
> This method turns things around 180 degrees from how one ordinarily thinks
> about XML Schema design. When designing schemas one doesn’t ordinarily
> think, “Oh, I’ll let the context (environment) schema documents provide the
> content here.”
>
> While it does require a mental shift, I think method 5 may be capable of
> modeling the real world in a better way. After all, in the real world
> context plays a key role in most everything. Method 5 simply reflects that.
>
>
>
> Questions for you:
>
>
>
> 1.       Have you used the Method 5 approach? Did it work out well?
>
> 2.       What other advantages and disadvantages do you see for Method 5?
>
>
>
> /Roger



-- 
Regards,
Mukul Gandhi

Great discussion!

John Cowan wrote:

> Tim Bray's stuff on internationalization (back when it was a new 
> and radical idea) showed that the cost of i18n at development time 
> is about 10%, whereas after the fact it's about 100%.

John, do you have a reference for this, that shows the numbers you cite?

> This is a specific case of a more general point ...

Again, it would be awesome to have a reference for this. Is this a documented principle that you are describing?

> it is always simplest to hard-code all assumptions, but 
> it *will* force redesign further down the line, and the 
> more assumptions, the more redesign.  

In the case of the discussion at hand, the assumption is what? Is it the following? Assumption: The larger XML community will always use XML Schema so just create data models using XML Schema. 

/Roger

On 01/02/12 15:21, Michael Kay wrote:
> On 01/02/2012 14:44, Tei wrote:
>> On 1 February 2012 13:08, David Lee<dlee@calldei.com> wrote:
>> ...
>>> Encoding still is a hard problem but I can't accept that Ignorance
>>> was the
>>> cause of it missing from the HTTP specs.
>>>
>> Using ascii was a adecuate solution. Solved the problem at the time,
>> for the people that needed a solution. Maybe not for everyone forever,
>> but that can be solved by new protocols.
>>
> Well, for some of the people that needed a solution, anyway.
>
> More to the point, the Europeans were locked in debate over ideal
> standards like X.400 and ODA that solved every requirement under the
> sun, while the Americans just hacked together something that worked; and
> most of the Americans had never met anyone with an umlaut in their name.

The OSI stuff was truly a nightmare to implement. An object lesson in 
how not to construct a suite of protocols. Perhaps the sole legacies of 
X.500 are the ghastly mess that is AD internals, and the use of the word 
"distinguished" :-)

> Cheap and cheerful won the day, and we are all still paying the price.

"If English was good enough for Jesus Christ, it's good enough for me"

:-)

///Peter

On 01/02/12 17:29, Uche Ogbuji wrote:
> On Wed, Feb 1, 2012 at 9:55 AM, Michael Kay <mike@saxonica.com
> <mailto:mike@saxonica.com>> wrote:
[...]
>     No, XML Schema is far worse, it's a que-perfecto �ber-spec that sees
>     lots of practical use.
>
> Interestingly, Michael, I think you are one of the exceedingly rare
> people who put WXS to practical use, and I've always been in awe of your
> capacity to do so. I think that 95% of WXS use is not practical at all,
> but rather sheer busy-work.
>
> Of course that's just my blinkered anecdotal perspective, but I can't
> tell you how many times I've been got on a project and they proudly say
> "here's our schema!!!!!" and dump a full ream of useless, inscrutable
> xsd:alphabetSoup that no one really even comes close to understanding,
> and thus gets ignored throughout most of their actual processing.

I have lost count of the projects whose first task was to strip all 
namespaces and cut the XSD down to a DTD representing only the element 
types that were actually used. In only a few cases have I been able to 
persuade them to do the modelling in RNG and recreate a minimally 
workable Schema. But this is solid text-document XML, with more 
character data content than markup :-)

///Peter

On 01/02/12 16:53, Pete Cordell wrote:
> Ignorance is a very acceptable excuse in IMO. Talking to computers was a
> very ASCII affair in those days (e.g. C) and it would seem reasonable
> that computers would talk to computers in the same way.
>
> My recollection is that for those of us who weren't Internationalisation
> gurus, choosing Latin-1 was considered really pushing the
> Internationalisation boat out!

There was certainly an element of that at the time. But a lot of the 
effort was really on the traditional basis of rough consensus and 
running code. A lot of this stuff was still relatively new, and only a 
few people were thinking of non-European or non-Latin-alphabet languages.

And I see that Unicode added another 700-odd characters to the 
repertoire recently...

///Peter

On 2012-02-01 17:23, Richard Salz wrote:
> My wording wasn't clear enough.
>
> At the time, we all thought "netascii for headers" was the right thing to
> do.  So much so that the question of codesets in headers *never came up.*
> The entire IETF had this mindset, it was a truism, fundamental concept,
> statement of fact, fundamental postulate, etc. It was not "what about
> charset encodings?  Never mind"
>
> I use the pronoun "we" on purpose;
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec16.html#sec16
> ...

Which is a good opportunity to remind people that IETF specifications 
are influenced by those people who care enough to show up and help.

<http://trac.tools.ietf.org/wg/httpbis/trac/wiki>

Now is the time.

> How can I design today so that tomorrow I can nimbly change to a new validation language? Are there concrete, practical things that can be done today? Perhaps one thing that can be done is to require every data model be implemented in both XML Schema and Relax NG. What else?
>

One approach is: do nothing. Incur that cost if and when it's actually
needed, don't waste your time/effort/money on it now.



-- 
Andrew Welch
http://andrewjwelch.com

Improved conversion tools would be a good start.  In fact probably a
precondition for the en masse migration ..

Bob

On 1 February 2012 19:30, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
> Suppose that in the future the tide shifts and the XML world moves en masse away from XML Schema to Relax NG (or some other simple, powerful language with a strong formal basis).
>
> Let's assume that validating XML instance documents is required.
>
> When the day arrives to shift to Relax NG I wish to make the shift with minimal breakage and cost.
>
> How can I design today so that tomorrow I can nimbly change to a new validation language? Are there concrete, practical things that can be done today? Perhaps one thing that can be done is to require every data model be implemented in both XML Schema and Relax NG. What else?
>
> /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,

Suppose that in the future the tide shifts and the XML world moves en masse away from XML Schema to Relax NG (or some other simple, powerful language with a strong formal basis).

Let's assume that validating XML instance documents is required.

When the day arrives to shift to Relax NG I wish to make the shift with minimal breakage and cost.

How can I design today so that tomorrow I can nimbly change to a new validation language? Are there concrete, practical things that can be done today? Perhaps one thing that can be done is to require every data model be implemented in both XML Schema and Relax NG. What else?

/Roger

Original Message From: "John Cowan"
> Pete Cordell scripsit:
>
>> How about:
>> "A designer knows he has achieved something right when everybody
>> complains he has done something wrong!"
>
> Unless the complaints are all the same.  The IBM PCjr chiclet keyboard
> really did [expletive deleted], just like everyone said it did.  It's when some are
> saying "Too much!" and others "Not enough!" that you know you've hit on
> the perfect compromise.

I was thinking more along the lines of if nobody complains, then nobody 
cares.  I don't think many complain about X.400 these days.

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: "John Cowan" <cowan@mercury.ccil.org>
To: "Pete Cordell" <petexmldev@codalogic.com>
Cc: <Toby.Considine@gmail.com>; <xml-dev@l...>
Sent: Wednesday, February 01, 2012 6:41 PM
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication


> Pete Cordell scripsit:
>
>> How about:
>> "A designer knows he has achieved something right when everybody
>> complains he has done something wrong!"
>
> Unless the complaints are all the same.  The IBM PCjr chiclet keyboard
> really did [expletive deleted], just like everyone said it did.  It's when some are
> saying "Too much!" and others "Not enough!" that you know you've hit on
> the perfect compromise.
>
> -- 
> John Cowan      <cowan@ccil.org>       http://www.ccil.org/~cowan
>                Charles li reis, nostre emperesdre magnes,
>                Set anz totz pleinz ad ested in Espagnes. 

Original Message From: "Toby Considine"

> "A designer knows he has achieved perfection not
> when there is nothing left to add, but when there is
> nothing left to take away."
 -Antoine de Saint-Exupery

How about:
"A designer knows he has achieved something right when everybody complains 
he has done something wrong!"

:-)

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: Wednesday, February 01, 2012 5:36 PM
Subject: RE:  RE: Encoding charset of HTTP Basic Authentication


I think it was the original developer of HTTP who was quoted along the lines 
of "If I had known so many people were going to use it, and how important it 
was going to be,  I wouldn't have done such a poor job. "

The work done then was successful and timely enough that it has created the 
time/attention/interest/need for a more nuanced solution. If they had waited 
for the nuances then, we might never have cared.


"A designer knows he has achieved perfection not when there is nothing left 
to add, but when there is nothing left to take away."
-Antoine de Saint-Exupery

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: David Lee [mailto:dlee@calldei.com]
Sent: Wednesday, February 01, 2012 6:54 AM
To: 'Tei'; xml-dev@lists.xml.org
Subject: RE:  RE: Encoding charset of HTTP Basic Authentication

But the funny thing is that ASCII wasnt what the browsers and servers 
actually implemented typically it was ISO-8859-1

Oh well the past is the past.
Now we just have to pile on higher to reach higher


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


-----Original Message-----
From: Tei [mailto:oscar.vives@gmail.com]
Sent: Wednesday, February 01, 2012 9:44 AM
To: xml-dev@lists.xml.org
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication


On 1 February 2012 13:08, David Lee <dlee@calldei.com> wrote:
...
>
> Encoding still is a hard problem but I can't accept that Ignorance was the
> cause of it missing from the HTTP specs.
>

Using ascii was a adecuate solution. Solved the problem at the time,
for the people that needed a solution. Maybe not for everyone forever,
but that can be solved by new protocols.




-- 
--
ℱin del ℳensaje.

_______________________________________________________________________

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



_______________________________________________________________________

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

Petite Abeille scripsit:

> Fair enough. FWIW, my personal experience is the exact opposite:
> pointless, bloated, big design up-front, busy work which never gets
> anything done. But as always, YMMV.

Believe me, I've had plenty of experience of that.  If you truly aren't
going to need something, YAGNI is a huge win.  But there's no reason to
pretend that just because this is only the first report you are writing,
that there won't be hundreds more reports.

-- 
Why are well-meaning Westerners so concerned that   John Cowan
the opening of a Colonel Sanders in Beijing means   cowan@ccil.org
the end of Chinese culture? [...]  We have had      http://www.ccil.org/~cowan
Chinese restaurants in America for over a century,
and it hasn't made us Chinese.  On the contrary,
we obliged the Chinese to invent chop suey.            --Marshall Sahlins

On 01/02/2012 16:19, John Cowan wrote:
> Uche Ogbuji scripsit:
>
>> Never mind the small detail that said catastrophically ignorant
>> and broken specs brought us the modern, global Web as we enjoy it
>> today while people were toiling in mega-man committees te world over
>> on que-perfecto über-specs that never really ended up seeing any
>> practical use.
> Oh, you mean like XML Schema?
>
No, XML Schema is far worse, it's a que-perfecto über-spec that sees 
lots of practical use.

Michael Kay
Saxonica

Costello, Roger L. scripsit:

> John, do you have a reference for this, that shows the numbers you cite?

Not that I can easily lay my hands on.  You could ask Tim.

Poking about on the C2 wiki, I find an anecdote of someone doing i18n
in a well-factored English-only algorithm with very little work.  However,
I bet he was not using a "bytes=characters" language like C.

> > This is a specific case of a more general point ...
> 
> Again, it would be awesome to have a reference for this. Is this a
> documented principle that you are describing?

There's plenty of talk about it in C2 and other XP sources: search for
[YAGNI counterexamples].

> > it is always simplest to hard-code all assumptions, but 
> > it *will* force redesign further down the line, and the 
> > more assumptions, the more redesign.  
> 
> In the case of the discussion at hand, the assumption is what? Is it
> the following? Assumption: The larger XML community will always use
> XML Schema so just create data models using XML Schema.

Something like that.

Petite Abeille scripsit:

> And what's wrong with redesign? After all, we are dealing with software,
> which, by its very nature, is infinitely malleable.

Change is not free.  XP advocates claim that if the rest of their
methods are followed, it costs no more to make a change later than to
make it now; my view of this claim is that "all theory is for it, but
all experience is against it."

In addition, not all software is malleable.  The extreme case is software
in ROM, which is not malleable except by buying a new device.  Short of that,
there is commercial software where customers are charged to upgrade, which
might as well be in ROM.  It's common enough for programs never to be upgraded
until a new PC with new software is bought.

-- 
I now introduce Professor Smullyan,             John Cowan
who will prove to you that either               cowan@ccil.org
he doesn't exist or you don't exist,            http://www.ccil.org/~cowan
but you won't know which.                               --Melvin Fitting

Ignorance is a very acceptable excuse in IMO.  Talking to computers was a 
very ASCII affair in those days (e.g. C) and it would seem reasonable that 
computers would talk to computers in the same way.

My recollection is that for those of us who weren't Internationalisation 
gurus, choosing Latin-1 was considered really pushing the 
Internationalisation boat out!

http://www.w3.org/Protocols/HTTP/HTTP2.html (1992)
http://en.wikipedia.org/wiki/ISO/IEC_8859-1 (1987)

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: "'Richard Salz'" <rsalz@us.ibm.com>; <xml-dev@l...>
Sent: Wednesday, February 01, 2012 4:01 PM
Subject: RE:  RE: Encoding charset of HTTP Basic Authentication


> Richard says
> -------
>
> Nobody really questioned the belief that "netascii" was required for
> maximum interop.
>
> You want to call that Ignorance, go ahead.  I'd just say "we didn't know."
> -----------
>
>
> No exactly *not* my point.
> I am saying it could *NOT* have been ignorance.  I simply cannot accept 
> that
> the spec authors were ignorant of the shortcomings of not (or under)
> specifying encoding issues.   They just chose to ignore them on purpose.
> Probably for good reasons, like it was hard and not useful to them at the
> time to hash it out.  Not blaming them to come up with a spec that worked
> for the use cases they put it to.  Just saying it was a choice, not
> "ignorance".
>
>
>
>
>
> ----------------------------------------
> David A. Lee
> dlee@calldei.com
> http://www.xmlsh.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
> 

General Atomics Aeronautical in San Diego CA is looking for a tools 
developer to help support our IETM development and support the team 
of writers. We are looking for just about any combination of these skills:

- S1000D
- DITA
- Mil Spec publishing background
- Army IADS development
- SGML
- FOSI
- Arbortext customization
- Perl, Javascript, Java
- XML

This is a full time direct position and is located in Poway (outside 
San Diego). For complete details see

https://search9.smartsearchonline.com/asi/jobs/jobdetails.asp?current_page=1&city=&location=&job_type=&emp_status=&direct_jo_num=&country=&k1=IETMS&k2=&k3=&k4=&k5=&k6=&k7=&k8=&salary_min=&co_num=&apply=yes&job_number=11446

or contact me directly at dvint@dvint.com
---------------------------------------------------------------------------
Danny Vint

Panoramic Photography
http://www.dvint.com

voice: 619-938-3610
     

Peter Flynn scripsit:

> The OSI stuff was truly a nightmare to implement. An object lesson in  
> how not to construct a suite of protocols. Perhaps the sole legacies of  
> X.500 are the ghastly mess that is AD internals, and the use of the word  
> "distinguished" :-)

Well, LDAP is hardly dead.

-- 
John Cowan              http://www.ccil.org/~cowan      cowan@ccil.org
Would your name perchance be surname Puppet, given name Sock?
                --Rick Moen

Andrew Welch scripsit:

> One approach is: do nothing. Incur that cost if and when it's actually
> needed, don't waste your time/effort/money on it now.

I have never cared for this idea, and indeed there are many obvious
counterexamples.  Tim Bray's stuff on internationalization (back
when it was a new and radical idea) showed that the cost of i18n at
development time is about 10%, whereas after the fact it's about 100%.
This is a specific case of a more general point: it is always simplest
to hard-code all assumptions, but it *will* force redesign further
down the line, and the more assumptions, the more redesign.  Hiding
the assumptions behind an abstract interface doesn't help, for that
interface has hard-wired assumptions too.  And so on.

-- 
John Cowan              http://www.ccil.org/~cowan      cowan@ccil.org
Would your name perchance be surname Puppet, given name Sock?
                --Rick Moen

On 1 February 2012 13:08, David Lee <dlee@calldei.com> wrote:
...
>
> Encoding still is a hard problem but I can't accept that Ignorance was the
> cause of it missing from the HTTP specs.
>

Using ascii was a adecuate solution. Solved the problem at the time,
for the people that needed a solution. Maybe not for everyone forever,
but that can be solved by new protocols.




-- 
--
ℱin del ℳensaje.

On 01/02/2012 14:44, Tei wrote:
> On 1 February 2012 13:08, David Lee<dlee@calldei.com>  wrote:
> ...
>> Encoding still is a hard problem but I can't accept that Ignorance was the
>> cause of it missing from the HTTP specs.
>>
> Using ascii was a adecuate solution. Solved the problem at the time,
> for the people that needed a solution. Maybe not for everyone forever,
> but that can be solved by new protocols.
>
Well, for some of the people that needed a solution, anyway.

More to the point, the Europeans were locked in debate over ideal 
standards like X.400 and ODA that solved every requirement under the 
sun, while the Americans just hacked together something that worked; and 
most of the Americans had never met anyone with an umlaut in their name. 
Cheap and cheerful won the day, and we are all still paying the price.

Michael Kay
Saxonica

Costello, Roger L. scripsit:

> How can I design today so that tomorrow I can nimbly change to a new
> validation language? Are there concrete, practical things that can be
> done today? Perhaps one thing that can be done is to require every
> data model be implemented in both XML Schema and Relax NG. What else?

$EMPLOYER's practice is to write all schemas in RELAX NG (except for
some legacy DTDs), and convert them to XSD using Trang for delivery to
implementation groups.  We make sure that our sample documents are valid
against both schemas.

The RNG Converter at
http://java.net/downloads/msv/nightly/rngconv.20060319.zip can be used
to convert an XML Schema including all imports to a monolithic RELAX
NG grammar.  It does not preserve modularization, and ignores xsd:key,
xsd:keyref, and xsd:unique declarations.

-- 
Here lies the Christian,                        John Cowan
        judge, and poet Peter,                  http://www.ccil.org/~cowan
Who broke the laws of God                       cowan@ccil.org
        and man and metre.

Pete Cordell scripsit:

> How about:
> "A designer knows he has achieved something right when everybody 
> complains he has done something wrong!"

Unless the complaints are all the same.  The IBM PCjr chiclet keyboard
really did [expletive deleted], just like everyone said it did.  It's when some are
saying "Too much!" and others "Not enough!" that you know you've hit on
the perfect compromise.

-- 
John Cowan      <cowan@ccil.org>       http://www.ccil.org/~cowan
                Charles li reis, nostre emperesdre magnes,
                Set anz totz pleinz ad ested in Espagnes.

On 30 January 2012 15:44, David Lee <dlee@calldei.com> wrote:
> Were back to the problem that SSL doesn't solve the problem (today)  it was
> originally intended to solve.   But it happens to solve *this* problem (as
> long as you ignore the fact that both ends may be insecure - in which case
> all bets are off).
>
> But yes the crux is that Authentication in pure HTTP is either insecure or
> hard.
> That's just the way it is (as far as I know).
>
> <rant>
> This is why a particular annoyance of mine is the false-sense-of-security of
> CA signed certificates.
> If browsers didn't put up an ugly warning about how scary a self-signed
> certificate was then more people would use SSL and the internet would be
> more secure.
> But if you use plain HTTP you don't get a warning - just insecurity.
> Why is it like this ? My only guess ... "Follow the money ..." ?
>
> </rant>
>

Security conscient people seems to not like this idea, because MITM
attacks are easy with selfsigned certs.

Then recently some rogue certificates where generated, for google and
other domains.   The next time you pay something with Paypal, you
could be using some mitm Iranian server, or perhaps some CIA server.

For two years USA was reading Megavideo CEO emails. So storage is
another problem (don't put your secrets on the cloud as cleartext),
have your data in non-USA service.






-- 
--
ℱin del ℳensaje.

And the said broken-standards and specs from the mega-man committees  
those catastrophically ignorant specs set out to replace enabled the  
technologies that started the modern global web as some suffer it.

A man with a solution to a problem defends the problem and so it goes.

A bit more concentration on privacy and security would have been  
helpful but one man's suffering is another man's advantage in  
obtaining power and other people's property.

The U.S. House committee has already approved HR 1981.

len

Quoting John Cowan <cowan@mercury.ccil.org>:

> Uche Ogbuji scripsit:
>
>> Never mind the small detail that said catastrophically ignorant
>> and broken specs brought us the modern, global Web as we enjoy it
>> today while people were toiling in mega-man committees te world over
>> on que-perfecto über-specs that never really ended up seeing any
>> practical use.
>
> Oh, you mean like XML Schema?
>
> --
> 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
>
>
>

My wording wasn't clear enough.

At the time, we all thought "netascii for headers" was the right thing to 
do.  So much so that the question of codesets in headers *never came up.* 
The entire IETF had this mindset, it was a truism, fundamental concept, 
statement of fact, fundamental postulate, etc. It was not "what about 
charset encodings?  Never mind"

I use the pronoun "we" on purpose; 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec16.html#sec16

        /r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/

Uche Ogbuji scripsit:

> Never mind the small detail that said catastrophically ignorant
> and broken specs brought us the modern, global Web as we enjoy it
> today while people were toiling in mega-man committees te world over
> on que-perfecto über-specs that never really ended up seeing any
> practical use.

Oh, you mean like XML Schema?

-- 
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)

Richard says
-------

Nobody really questioned the belief that "netascii" was required for 
maximum interop.

You want to call that Ignorance, go ahead.  I'd just say "we didn't know."
-----------


No exactly *not* my point.
I am saying it could *NOT* have been ignorance.  I simply cannot accept that
the spec authors were ignorant of the shortcomings of not (or under)
specifying encoding issues.   They just chose to ignore them on purpose.
Probably for good reasons, like it was hard and not useful to them at the
time to hash it out.  Not blaming them to come up with a spec that worked
for the use cases they put it to.  Just saying it was a choice, not
"ignorance". 





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

> > Encoding still is a hard problem but I can't accept that Ignorance was 
the
> > cause of it missing from the HTTP specs.

Nobody really questioned the belief that "netascii" was required for 
maximum interop.

You want to call that Ignorance, go ahead.  I'd just say "we didn't know."

        /r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/

But the funny thing is that ASCII wasnt what the browsers and servers actually implemented typically it was ISO-8859-1

Oh well the past is the past.
Now we just have to pile on higher to reach higher


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


-----Original Message-----
From: Tei [mailto:oscar.vives@gmail.com] 
Sent: Wednesday, February 01, 2012 9:44 AM
To: xml-dev@lists.xml.org
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication


On 1 February 2012 13:08, David Lee <dlee@calldei.com> wrote:
...
>
> Encoding still is a hard problem but I can't accept that Ignorance was the
> cause of it missing from the HTTP specs.
>

Using ascii was a adecuate solution. Solved the problem at the time,
for the people that needed a solution. Maybe not for everyone forever,
but that can be solved by new protocols.




-- 
--
ℱin del ℳensaje.

_______________________________________________________________________

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 think it was the original developer of HTTP who was quoted along the lines of "If I had known so many people were going to use it, and how important it was going to be,  I wouldn't have done such a poor job. " 

The work done then was successful and timely enough that it has created the time/attention/interest/need for a more nuanced solution. If they had waited for the nuances then, we might never have cared. 


"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
-Antoine de Saint-Exupery

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: David Lee [mailto:dlee@calldei.com] 
Sent: Wednesday, February 01, 2012 6:54 AM
To: 'Tei'; xml-dev@lists.xml.org
Subject: RE:  RE: Encoding charset of HTTP Basic Authentication

But the funny thing is that ASCII wasnt what the browsers and servers actually implemented typically it was ISO-8859-1

Oh well the past is the past.
Now we just have to pile on higher to reach higher


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


-----Original Message-----
From: Tei [mailto:oscar.vives@gmail.com] 
Sent: Wednesday, February 01, 2012 9:44 AM
To: xml-dev@lists.xml.org
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication


On 1 February 2012 13:08, David Lee <dlee@calldei.com> wrote:
...
>
> Encoding still is a hard problem but I can't accept that Ignorance was the
> cause of it missing from the HTTP specs.
>

Using ascii was a adecuate solution. Solved the problem at the time,
for the people that needed a solution. Maybe not for everyone forever,
but that can be solved by new protocols.




-- 
--
ℱin del ℳensaje.

_______________________________________________________________________

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

 >The distinction between bytes and characters is a fairly recent 
development. When I bought my first computer in the 1990s it came with 
Windows 3.11 and MS-DOS 6.22, and the german versions of those use 
different "code pages"...


In the Computer Science Tripos at Cambridge University they always used 
to ask a few open-ended questions, and I remember one from the early 
1970s along the lines "Why is character encoding such a difficult thing 
to get right?" Forty years on, getting it right hasn't become any easier.

However, I think any student answering that question would have been 
expected to understand the difference between characters and the bytes 
used to represent them.

Michael Kay
Saxonica

Agree with Michael.
Character encoding is *not* a recent problem.  It may still be hard, but its
not recent.  Back when I was getting my Amateur Radio License (1970ihs?) I
remember a strong petition to the FCC to try to allow amateur teletype to
use ASCII instead of BAUDOT.  'Everyone' knew IBM machines used EBCIDIC ...
(and lets not talk about Morse Code, an early multi-bit character encoding).
Even those old DOS boxes had 'CodePages'.    People talk about DOS a lot but
really most of the early internet machines were Unix.    Of course Unix (now
Linux) still doesn't solve character encoding issues very well.    

Encoding still is a hard problem but I can't accept that Ignorance was the
cause of it missing from the HTTP specs. 

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


-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com] 
Sent: Wednesday, February 01, 2012 3:40 AM
To: xml-dev@lists.xml.org
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication


 >The distinction between bytes and characters is a fairly recent 
development. When I bought my first computer in the 1990s it came with 
Windows 3.11 and MS-DOS 6.22, and the german versions of those use 
different "code pages"...


In the Computer Science Tripos at Cambridge University they always used 
to ask a few open-ended questions, and I remember one from the early 
1970s along the lines "Why is character encoding such a difficult thing 
to get right?" Forty years on, getting it right hasn't become any easier.

However, I think any student answering that question would have been 
expected to understand the difference between characters and the bytes 
used to represent them.

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

===> Tei sez 
Security conscient people seems to not like this idea, because MITM
attacks are easy with selfsigned certs.
<====

Of course its not perfect, practically nothing is.
But my point is using SSL with self-signed certificates is more vastly more secure than using HTTP with plain text. But the browsers give a Horrendously scary warning if you use SSL with self-signed certificates and say nothing at all for plain text HTTP (except the lack of a microscopic lock icon).
This leads many (most?) web site developers to just stick to plain HTTP.  Thus decreasing security overall
I simply don't understand that.

-David

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

* David Lee wrote:
>What shocks *me* is that the intent of base64 is stated to allow more
>characters then HTTP headers allow but then due to the lack of
>encoding/charset specification allows precious few.
>A lot of work for almost nothing.  A simple insertion of the text "UTF8
>encoded prior to base64" would have nailed it.

The distinction between bytes and characters is a fairly recent develop-
ment. When I bought my first computer in the 1990s it came with Windows
3.11 and MS-DOS 6.22, and the german versions of those use different
"code pages", meaning plain text files with Umlauts that I created in
DOS did not work right under Windows and vice versa.

Some years later when I got an Internet connection at home I chatted
with an egyptian girl living egypt over ICQ. She wanted to send me a
letter and asked for my address, and she asked about the characters in
my name and address and I tried hard to explain umlauts and that I use
"oe" in my "nickname" as transliteration... and eventually I got her
letter containing mojibake where the umlauts should have gone.

It's not something that was wired into people's heads at the time, and
we are still suffering from that. If I put my proper name into the From
header I will without a doubt see my name mangled in replies or online
archives shortly after. Heck, in back in 2004 I filed comments on W3C's
Character Model for the World Wide Web specification, developed by the
I18N Working Group there, through an online form they developed, and my
name came out as mojibake in the list archive where the comments were
copied to.

Note that this is in part due to missing infrastructure, in the DOS/Win-
dows case, apart from heuristics software would have had no means to de-
cide whether something was a Windows plain text file or a DOS plain text
file. Months ago I made a Perl script that renames audio files based on
meta data, and the built-in renaming function did not work right, I had
to use a special Win32::Unicode::File module to get the right names. We
are still paying this technical debt off.

(The authors of RFC 2617 should probably have known better due to RFC
2277, it might be interesting to find out why/if this issue was missed.)
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

On 31/01/12 20:54, Markus Braun wrote:
> I have this code:
> 
> #/usr/bin/env ruby
> require 'rubygems'
> require 'nokogiri'
> require 'open-uri'
> 
> doc =
> Nokogiri::HTML(open("http://mobile.bahn.de/bin/mobil/bhftafel.exe/dox?input=Richard-Strauss-Stra%DFe%2C+M%FCnchen%23625127&date=27.01.12&time=20%3A41&productsFilter=1111111111000000&REQTrain_name=&maxJourneys=10&start=Suchen&boardType=Abfahrt&ao=yes"))
> doc = doc.xpath('//div').each do |node|
> doc.remove_namespaces!
>  puts node.text
> end
> 
> 
> but get to many blank spaces...
> 
> how can i remove it?

Ask in the right place, like comp.lang.ruby
This mailing list is for XML, not Ruby.

>> From: liam@w3.org
[snip]
>> Sometimes working out who to ask is a large part of getting an answer.

Amen

///Peter

On 2012-01-31 00:43, David Lee wrote:
>
> --- David
> A simple insertion of the text "UTF8
>   encoded prior to base64" would have nailed it.
>
> ------ Julian
> If you actually had read the spec, you would know why that doesn't work.
>
> Unless you mean: "back in 1997" (RFC 2068).
> ---------
> Yes I "actually" read the spec but no I dont know why that wouldn't work.
> Maybe you could enlighten me ?

Many UAs use ISO-8859-1, and many servers expect that.

 > ...

Best regards, Julian

On 2012-01-29 20:53, David Lee wrote:
> More study and I lucked on a spec
> 
> http://tools.ietf.org/id/draft-reschke-basicauth-enc-00.html

->
<http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html>

> Seems a known and open problem (how long has this been in the wild ? How 
> did it ever work ?)

It "worked" as long everybody was happy with ISO-8859-1.

> So follow-on question ...
> 
> Does anyone know if this spec or anything like it has been adopted ?

No, it hasn't been adopted, but I'm trying to get it to IETF Last Call.

> Or do we just all assume the world is "USASCII" as usual ?

I don't think that's sufficient :-)

Best regards, Julian

On 2012-01-30 00:49, David Lee wrote:
> Great link Petite ! Finally someone put words to my vague opinions.
> As for Basic Authentication base64 ... Why the shock ?
> The specs clearly state  base64 is not intended for "encryption" ...
>
> And the facts (IMHO) is that Basic Authentication is no more or less secure
> then
> entering user&  password in form fields.
>
> What shocks *me* is that the intent of base64 is stated to allow more
> characters then HTTP headers allow but then due to the lack of
> encoding/charset specification allows precious few.
> A lot of work for almost nothing.  A simple insertion of the text "UTF8
> encoded prior to base64" would have nailed it.
> ...

If you actually had read the spec, you would know why that doesn't work.

Unless you mean: "back in 1997" (RFC 2068).

Best regards, Julian

On Mon, 2012-01-30 at 21:41 +0000, Markus Braun wrote:

> Hi like to code something like this:
> 
> https://github.com/muhkuh0815/siriproxy-Eyelp
> 
> so the entry is over the voice...

This would involve using Apple APIs I expect. No idea, there's not even
an apple store here, and I don't see people using iphones...

> at the moment i have this example but in this example the
> searchmachine has a backend in xml and formats the text in the right
> form.
> 
> but the m.bahn.de has not an xml format when i submit a request.

So you have three choices:
(1) write (or uuse) a backend at m.bahn.de, or talk with them about it
(2) write a proxy on another system that converts the results, or
(3) write ruby code for your portable telephone to handle the actual
results.

None of these relates to XML - the plugin on git you mention appears to
use JSON and not XML.

So, you need help from someone programming in the ruby environment on an
iphone with siri, it seems.  Sometimes working out who to ask is a large
part of getting an answer.

Liam
		 	   		  

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

--- David
A simple insertion of the text "UTF8
 encoded prior to base64" would have nailed it.

------ Julian
If you actually had read the spec, you would know why that doesn't work.

Unless you mean: "back in 1997" (RFC 2068).
---------
Yes I "actually" read the spec but no I dont know why that wouldn't work.
Maybe you could enlighten me ? 
Maybe it's that time travel thing where UTF8 was invented after HTTP ... ?
Is that to which you were referring ?
I've been around for both but honestly can't remember which came first, the
chicken or the egg.


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

On Jan 30, 2012, at 4:31 PM, Richard Salz wrote:

> It's worse because 

Soon! In a theatre near you! Such a cliffhanger!

On Jan 30, 2012, at 2:52 PM, Pete Cordell wrote:

> A quick question before I do though, does Digest require the server to have access to the password in clear text form, whereas Basic allows the server to store the password in some hashed form?

That's the crux of it: digest is not worth the complications IMO.

If you care about the integrity of the transport channel, use TLS.

If you use TLS, basic is all what you need.

I'm surprised I'm in a minority of one on this.  I've snipped out lots of 
comments in a reply, but my basic position is that we shouldn't be adopting 
a "buyer beware" position when it comes to handling passwords when we know 
there are better ways to do it, and we have known that for the best part of 
a decade.

The upside of this is that I will be delving into my server configs and 
changing them to use Digest if I can.  So I'm pleased that the topic has 
been raised from that point of view.

A quick question before I do though, does Digest require the server to have 
access to the password in clear text form, whereas Basic allows the server 
to store the password in some hashed form?

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
----- Original Message ----- 
From: "Greg Hunt" <greg@firmansyah.com>
To: "Pete Cordell" <petexmldev@codalogic.com>
Cc: "xml-dev" <xml-dev@lists.xml.org>
Sent: Monday, January 30, 2012 11:29 AM
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication


> Surely most of us here get paid to know how things work and what their
> strengths and weaknesses are.  The level of knowledge is sadly lower than
> it should be, but to paraphrase you, thats no excuse.  I don't think that
> digest was part of HTTP 1.0 and retiring standards is difficult.
>
> This, and the original issue, about character sets, is just evidence that
> things change; the industry's accepted level of knowledge and ideas of 
> good
> practice evolves and its up to us to understand the history.  The
> difficulty in using anything other than 8859-1 in post data (not exactly a
> lot of difficulty, but enough to cause a recurring class of unicode
> handling bug that people ring me up about) is probably another wrinkle
> related to what caused the lack of specification of the character set
> hidden in the base64 encoding.  The past had a different set of problems 
> to
> the present.  There was a page linked to earlier in this thread that
> asserted that the SSL threat model is entirely wrong, Perhaps today that 
> is
> true, but if you go back to the mid 90s there were large scale intrusions
> into network core routers, the network WAS relatively insecure and the
> security problem was not mostly trojans and key loggers on Windows
> desktops. We have to live with the past, more and more of it in IT as time
> goes by.
>
> On Mon, Jan 30, 2012 at 8:46 PM, Pete Cordell 
> <petexmldev@codalogic.com>wrote:
>
>> Original Message From: "Michael Sokolov"
>>
>> (I've flipped the order of Michael's reply to make the more important
>> comment first.)
>>
>>
>>  But yes, it's not good for public-facing auth, etc, and probably people
>>> (like you!) who don't know what it is have used it as if it were secure,
>>> so for that reason I agree with you, it's not the sort of standard that
>>> should be promulgated.
>>>
>>
>> I think that's the rub.  We all know that passwords should be kept 
>> secret,
>> and for a mechanism whose primary purpose is to exchange passwords it
>> surely
>> has a duty of care to help maintain that secrecy.  Sending passwords over
>> the Internet in the clear seems no more acceptable than storing passwords
>> in
>> a file in plain text.  No serious system would do the latter, so I think
>> it's only reasonable that we should object when systems do the former. 
>> "We
>> never said it was secure" is not an acceptable defence IMHO.
>>
>>
>>  It's actually pretty useful as an insecure *identification* mechanism. 
>> EG
>>> if you're operating inside a firewall and just want to give people a
>>> mechanism to say who they are, allowing for the fact someone might
>>> impersonate someone else, etc.  Not every authentication mechanism has 
>>> to
>>> be secure, just like not every door has to be locked - I mean do you 
>>> lock
>>> your bathroom door?  Closing it is enough; people knock and identify
>>> themselves.
>>>
>>
>> True, but it doesn't seem so much harder to always use Digest.  Surely 
>> it's
>> just calling a different function for most people?  (Digest may have its
>> weaknesses too, but that's a reason for making a stronger scheme rather
>> than
>> giving up completely.)
>>
>> I feel a bit like a disgruntled customer who's found his product doesn't 
>> do
>> what he thought it did based on the shining ads who on ringing into a 
>> help
>> line is told that I should have read the small print on page 215 :-)
>>
>>
>> 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: "Michael Sokolov" 
>> <sokolov@ifactory.com
>> >
>> To: "Pete Cordell" <petexmldev@codalogic.com>
>> Cc: "Petite Abeille" <petite.abeille@gmail.com>; "xml-dev"
>> <xml-dev@lists.xml.org>
>> Sent: Sunday, January 29, 2012 10:31 PM
>>
>> Subject: Re:  RE: Encoding charset of HTTP Basic Authentication
>>
>>
>>  It's actually pretty useful as an insecure *identification* mechanism. 
>> EG
>>> if you're operating inside a firewall and just want to give people a
>>> mechanism to say who they are, allowing for the fact someone might
>>> impersonate someone else, etc.  Not every authentication mechanism has 
>>> to
>>> be secure, just like not every door has to be locked - I mean do you 
>>> lock
>>> your bathroom door?  Closing it is enough; people knock and identify
>>> themselves.
>>>
>>> But yes, it's not good for public-facing auth, etc, and probably people
>>> (like you!) who don't know what it is have used it as if it were secure,
>>> so for that reason I agree with you, it's not the sort of standard that
>>> should be promulgated.
>>>
>>> -Mike
>>>
>>> On 1/29/2012 5:15 PM, Pete Cordell wrote:
>>>
>>>> Holy s*** you're right.  Just used wireshark on some HTTP exchanges. 
>>>> All
>>>> this talk about online security and they effectively allow Base64 as an
>>>> 'encryption' algorithm!  People should go to jail for that!  Still 
>>>> think
>>>> it's a bad, bad, bad idea.  SIP has deprecated it and Twitter has
>>>> disabled it.  As I said, I'm pretty sure the IETF wouldn't accept
>>>> something similar to it these days.
>>>>
>>>> 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: "Pete Cordell"
>>>> <petexmldev@codalogic.com>
>>>> To: "Petite Abeille" <petite.abeille@gmail.com>; "xml-dev"
>>>> <xml-dev@lists.xml.org>
>>>> Sent: Sunday, January 29, 2012 9:35 PM
>>>> Subject: Re:  RE: Encoding charset of HTTP Basic 
>>>> Authentication
>>>>
>>>>
>>>>  Convenient doesn't mean good though.  I think it _can_ be used over 
>>>> TLS,
>>>>> but since HTTP needs to support other schemes for non-TLS I can't see
>>>>> the point. I don't think it would accepted if it was introduced today.
>>>>>
>>>>> 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: "Petite Abeille"
>>>>> <petite.abeille@gmail.com>
>>>>> To: "xml-dev" <xml-dev@lists.xml.org>
>>>>> Sent: Sunday, January 29, 2012 8:33 PM
>>>>> Subject: Re:  RE: Encoding charset of HTTP Basic 
>>>>> Authentication
>>>>>
>>>>>
>>>>>
>>>>> On Jan 29, 2012, at 9:17 PM, Pete Cordell wrote:
>>>>>
>>>>>  My understanding is that Basic is essentially considered insecure
>>>>>>
>>>>>
>>>>> Basic is convenient, universally  supported, and meant to be used over
>>>>> TLS if you care about this kind of things.
>>>>>
>>>>> ______________________________**______________________________**
>>>>> ___________
>>>>>
>>>>> 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>
>>>>>
>>>>>
>>>>> ______________________________**______________________________**
>>>>> ___________
>>>>>
>>>>> 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>
>>>>>
>>>>>
>>>>
>>>> ______________________________**______________________________**
>>>> ___________
>>>>
>>>> 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>
>>>>
>>>>
>>>
>>> ______________________________**______________________________**
>>> ___________
>>>
>>> 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>
>>>
>>>
>>
>> ______________________________**______________________________**
>> ___________
>>
>> 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>
>>
>>
> 

> > password over the wire. It's worse because 
> 
> Arrgh!

See what happened -- I stopped typing to let my brain catch up, and it 
never did.... :)

Digest is worse because it never spec'd anything other than MD5, although 
it allowed "space" in the protocol for it.  (SHA was published a 
half-dozen years before.)  Unless the browser serializes requests (i.e., 
one image at a time), full integrity protection with digest usually [not 
always, see the last part of section 3.2.3 of RFC 2617 and sec 4.5 on 
replay] doubles the number of HTTP messages.  At that point, you might as 
well give up and use SSL/TLS, and once you've done that, the temptation to 
use basic-auth (but mom, everybody else does) is too generally too great 
to resist.

        /r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/

Richard Salz scripsit:

> The problem with basic-auth is that it requires the name/password to be 
> sent on every single request. The more a password is used, the more it as 
> at-risk. Even over SSL/TLS.  Digest is better because it never sends the 
> password over the wire. It's worse because 

Arrgh!

> Hope this helps.

Let's try that again, eh?

-- 
Knowledge studies others / Wisdom is self-known;      John Cowan
Muscle masters brothers / Self-mastery is bone;       cowan@ccil.org
Content need never borrow / Ambition wanders blind;   http://ccil.org/~cowan
Vitality cleaves to the marrow / Leaving death behind.    --Tao 33 (Bynner)

> My understanding is that Basic is essentially considered insecure.

Well, sending name/password over the Internet in the clear is bad. :) 
Basic-auth is just name/password encoded in base64.  It's not encrypted, 
nobody treats base64 as encryption. But back when basic-auth was created 
(like pre-apache golden oldie days), everyone on the internet was Gentle 
and Kind and followed Stimson's rule of "gentlemen don't read each other's 
mail."

One could say that base64 was chosen to future-proof and allow for 
multi-charset data, but I think that's kinda revisionist.  At the time of 
its definition, multiple charsets were not defined or in use in IETF 
protocol headers.

>  I'd be 
> surprised if modern browsers support it because it opens the way to a 
> man-in-the-middle downgrade attack.

I think you're confused.  Every single browser understands and supports 
basic-auth, and the HTTP status code for auth-required (401).  An MITM 
downgrade is when the adversary manages to trick both sides into using 
weaker security mechanisms, such as using DES insead of AES-256.  Digest 
is susceptible to MITM -- is that what you meant?

The problem with basic-auth is that it requires the name/password to be 
sent on every single request. The more a password is used, the more it as 
at-risk. Even over SSL/TLS.  Digest is better because it never sends the 
password over the wire. It's worse because 

Hope this helps.

        /r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/

Pete Cordell scripsit:

> I'm surprised I'm in a minority of one on this.  I've snipped out lots of 
> comments in a reply, but my basic position is that we shouldn't be 
> adopting a "buyer beware" position when it comes to handling passwords 
> when we know there are better ways to do it, and we have known that for 
> the best part of a decade.

We (if by "we" you mean human beings collectively) have known for decades
that two-factor authentication (two of "what you have", "what you know",
and "what you are") is the minimum requirement for decent security.
In particular passwords are a crappy implementation of "what you know",
since people most of the time either don't know them (the post-it on
the monitor) or do know them and so can anyone else.

-- 
John Cowan      cowan@ccil.org         http://www.ccil.org/~cowan
Statistics don't help a great deal in making important decisions.
Most people have more than the average number of feet, but I'm not about
to start a company selling shoes in threes. --Ross Gardler

Original Message From: "Michael Sokolov"

(I've flipped the order of Michael's reply to make the more important
comment first.)

> But yes, it's not good for public-facing auth, etc, and probably people
> (like you!) who don't know what it is have used it as if it were secure,
> so for that reason I agree with you, it's not the sort of standard that
> should be promulgated.

I think that's the rub.  We all know that passwords should be kept secret,
and for a mechanism whose primary purpose is to exchange passwords it surely
has a duty of care to help maintain that secrecy.  Sending passwords over
the Internet in the clear seems no more acceptable than storing passwords in
a file in plain text.  No serious system would do the latter, so I think
it's only reasonable that we should object when systems do the former.  "We
never said it was secure" is not an acceptable defence IMHO.

> It's actually pretty useful as an insecure *identification* mechanism.  EG
> if you're operating inside a firewall and just want to give people a
> mechanism to say who they are, allowing for the fact someone might
> impersonate someone else, etc.  Not every authentication mechanism has to
> be secure, just like not every door has to be locked - I mean do you lock
> your bathroom door?  Closing it is enough; people knock and identify
> themselves.

True, but it doesn't seem so much harder to always use Digest.  Surely it's
just calling a different function for most people?  (Digest may have its
weaknesses too, but that's a reason for making a stronger scheme rather than
giving up completely.)

I feel a bit like a disgruntled customer who's found his product doesn't do
what he thought it did based on the shining ads who on ringing into a help
line is told that I should have read the small print on page 215 :-)

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: "Michael Sokolov" <sokolov@ifactory.com>
To: "Pete Cordell" <petexmldev@codalogic.com>
Cc: "Petite Abeille" <petite.abeille@gmail.com>; "xml-dev"
<xml-dev@lists.xml.org>
Sent: Sunday, January 29, 2012 10:31 PM
Subject: Re:  RE: Encoding charset of HTTP Basic Authentication


> It's actually pretty useful as an insecure *identification* mechanism.  EG
> if you're operating inside a firewall and just want to give people a
> mechanism to say who they are, allowing for the fact someone might
> impersonate someone else, etc