But he doesn't want to do data extraction. He just wants to chunk up a large regular expression.

We need to be careful about a degree of nanny-ism, that just prevents people from getting the job done. The sure result of refusing to provide (abusable) general mechanisms is an explosion of specific mechanisms, until the committees will is sapped and they have to make decisiona about the boundary of what the provide is (since we cannot enumerate every use case). XSD tried to enumerate every case for parameter entities, and even then had to admit defeat at a certain point (which is surely what "redefine" is! Not only a sign of limits, but a kind of hygenic macro, in my eyes at least. Which is why all right-thinking people hate redefine, because it suggests life is more complicated than we can plan for.)

And then the users who, as night follows day, do have that "edge" case, are left hacking together some home-made macro system anyone.

Perhaps the exemplar for this is generics in OOP languages.  They really tried to avoid them, with classes and interfaces and traits and inheritences and so on. But ultimately they all still needed to add them: and generics are the most macro-like things you find.  Now, of course, I can see the advantage in annotations and DSLs that can be manipulated as things in their own right. But we shouldn't sneer at simple direct text replacement: it is not always BFI but sometimes the simplest and most elegant solution.

Regards

Rick

On Tue, Nov 21, 2017 at 12:05 PM, Michael Kay <mike@s...> wrote:

I've always been ambivalent about macros in general, largely because I've seen people use their power to build monstrous houses-built-on-sand that were wonderful to behold but impossible to understand or debug or change.

I've also been very ambivalent about XML's macro mechanism (entity expansion), largely because we don't have a data model or processing model/tools for manipulating XML documents with entities unexpanded, and if you're going to make serious use of entities for any kind of data abstraction then you need to be able to read and write the unexpanded view of the document programmatically.

Michael Kay

Saxonica

On 20 Nov 2017, at 23:24, Rick Jelliffe <rjelliffe@a...> wrote:

No.  

But what makes entities offensive? Seems like the appropriate technology to use.

In Schematron, you can put the text portions into variables and combine them. But it is ultimately still just text substitution (macros). XSD doesn't provide simple macros, but it doesn't need to, because XML does with entities.

The class-based programming movement in the 80s said that it would be better to figure out all the  cool things that macros (ccp, m4, etc) were used for should be elaborated into first-class language constructs  for better clarity, power etc. Hence C++ and OOP.  XSD is the last gasp of this movement.  The trouble is that there are uncountable things people can do with even simple macros: it severely restricts the expressivity (though not the power) of the language to not have any macro mechanism. (Schematron has 3 kinds of macros, if anyone is interested: simple macros with XPath variables and abstract rules, and parameterized macros with abstract patterns. You might say Schematron itself is a macro, actually...)

Regards

Rick

On Mon, Nov 20, 2017 at 11:35 PM, Costello, Roger L. <costello@m...> wrote:

Hi Folks,

 

I have an XML Schema that needs some complex regular expressions. I have been using <!ENTITY> to construct the regexes. See below. I find it pretty hard to debug these regular expressions. Is there a better way to construct regexes?  /Roger

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xsl:schema [
<!ENTITY Language-Tag "(&lang-tag;)|(&private-use;)|(&grandfathered;)">
<!ENTITY lang-tag "(&language;)(-&script;)?(-&region;)?(-&variant;)*(-&extension;)*(-&private-use;)?">
<!ENTITY language "([&ALPHA;]{2,3}(-&extlang;)?)|([&ALPHA;]{4})|([&ALPHA;]{5,8})">
<!ENTITY extlang "[&ALPHA;]{3}(-[&ALPHA;]{3}){0,2}">
<!ENTITY script "[&ALPHA;]{4}">
<!ENTITY region "([&ALPHA;]{2})|([&DIGIT;]{3})">
<!ENTITY variant "([&alphanum;]{5,8})|([&DIGIT;][&alphanum;]{3})">
<!ENTITY extension "((&singleton;)(-[&alphanum;]{2,8})+)">
<!ENTITY singleton "([&DIGIT;])|([A-W])|([Y-Z])|([a-w])|(y-z)">
<!ENTITY private-use "x(-[&alphanum;]{1,8})+">
<!ENTITY grandfathered "(&irregular;)|(&regular;)">
<!ENTITY irregular "(en-GB-oed)|(i-ami)|(i-bnn)|(i-default)|(i-enochian)|(i-hak)|(i-klingon)|(i-lux)|(i-mingo)|(i-navajo)|(i-pwn)|(i-tao)|(i-tay)|(i-tsu)|(sgn-BE-FR)|(sgn-BE-NL)|(sgn-CH-DE)">
<!ENTITY regular "(art-lojban)|(cel-gaulish)|(no-bok)|(no-nyn)|(zh-guoyu)|(zh-hakka)|(zh-min)|(zh-min-nan)|(zh-xiang)">
<!ENTITY ALPHA "a-zA-Z">
<!ENTITY DIGIT "0-9">
<!ENTITY alphanum "(&ALPHA;)|(&DIGIT;)">
]>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
   
    <xs:element name="language">
        <xs:simpleType>
            <xs:restriction base="xs:string">
                <xs:pattern value="&Language-Tag;" />
            </xs:restriction>
        </xs:simpleType>
    </xs:element>
   
</xs:schema>