I fed it a favorite regex... Bravo. Unfortunately, the permalinking fails with this particular regex, or I'd include it here. The visualization is so large, it more than fills my large screen. Still, pretty cool to see it render instantaneously and to watch it match example text. The regex is described here: http://www.cs.sfu.ca/~cameron/REX.html
It will match either text or XML markup (it's used to tokenize XML), so try example text like '<div id="123">abc' or 'abc<?xml target?>'.
The JavaScript form of the regex follows:
[^<]+|<(!(--([^-]-([^-][^-]-)->?)?|\[CDATA\[([^]]]([^]]+])]+([^]>][^]]]([^]]+])]+)>)?|DOCTYPE([ \n\t\r]+([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])|"[^"]"|'[^']'))([ \n\t\r]+)?(\[(<(!(--[^-]-([^-][^-]-)->|[^-]([^]"'><]+|"[^"]"|'[^']')>)|\?([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])(\?>|[\n\r\t ][^?]\?+([^>?][^?]\?+)>))|%([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F]);|[ \n\t\r]+)]([ \n\t\r]+)?)?>?)?)?|\?(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])(\?>|[\n\r\t ][^?]\?+([^>?][^?]\?+)>)?)?|/(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+)?>?)?|(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+)?=([ \n\t\r]+)?("[^<"]"|'[^<']'))*([ \n\t\r]+)?/?>?)?)
Wow. How the hell do you (OP) get it to render so fast? That was instantaneous as far as I could tell. I've seen websites take 5x as long to add a <li> to a <ul> ... I'm really amazed.
Even on my AMD E-450 netbook, that was pretty much instant. Lagged a lot afterwards (to be expected, running FF on elementary Luna), but way better than I thought it would! Well done OP, seriously well done.
The permalinking is very rudimentary and was put up quickly so that it worked for "most cases". I wanted to focus on building the actual debugger. This will be fixed in the near future.
Regarding business model and monetizing, here are some ideas:
1. You could sell tutorials and ebooks on regexes. People who use your tool might want to understand why their regexes are not working.
2. You could license your debugging code/technology.
3. You could sell a corporate license to use your site. Corps’s regexes won't be shared publicly. Others might be. Corps paranoid about people stealing their regexes might be interested in your product.
4. You could ask for donations to support the site.
5. You could make it social. Have people vote on regexes. Have another complementary site where people contribute test-cases for common regexes like phone numbers, dates, email addresses. You could hold competitions in different categories.
6. You could offer a cloud-based regex parser. I know it sounds a bit absurd, but I want to throw this out there in case it leads to other neat ideas.
7. You could save regexes and have people vote them up. You could have discussion threads around regexes.
4. You could ask for donations to support the site.
If you learn nothing else from Wikipedia, learn this: Begging annoys users and isn't particularly successful. He is far more likely to make money selling a premium subscription to corporate users. He can even just say "site is free for personal use, and corporate users must pay $495/year". You would be surprised at how many businesses are paranoid enough about compliance that they will voluntarily pay even if it is unlikely that the site owner would ever find out about their unauthorized corporate use.
Yes, and as the fifth most popular site in the world, that is a pittance. They could be making billions with unobtrusive advertising. Given their traffic, the fact that they only raised $25 million last year means that nearly all of their users ignored their pleas for help. Further, when they do their begging, it is very obtrusive and disruptive to the user experience. Where alternative revenue models are available, begging shouldn't even be a consideration.
One concern I saw mentioned was that after receiving advertising revenue, Wikipedia might become reliant on it, which would allow an advertiser to exert influence over the organization, such as demanding for articles to be removed that are negative to the advertiser's interests, with a threat to pull advertising funding.
But yes, I agree, it seems possible for WP to accept advertisement without compromising on its core values. Decide in advance never to give in to such demands, and do not take the funding for granted.
Deciding not to accept advertising might be short-sighted. With enough years of advertising revenue, Wikipedia might be able to work toward financial independence (where returns on investment exceed costs), and build an endowment like the sort that powers top universities.
They could set up a separate non-profit organisation (that donates its proceeds to the wikimedia foundation) to sell and manage the ads. Place the organisation in a city far from any wikimedia presence to counter casual contact. Put in the charter than there can be zero personnel overlap between the businesses at any level and that nobody at the ads company is allowed to edit any article on wikipedia or any reason, much less hold any admin credentials . Embrace openness: Publish as much as is practical about every deal, and make sure all ads on the sites are directly referenceable back to the deal in which they were purchased. Publish the names and resumes of all account managers.
That's true only if a site strictly uses a contextual advertising system. Most high-traffic sites sell specific ad space and time (AKA an ad campaign) to the highest bidder in order to supplement their normal advertising network.
Even if Wikipedia used the most unobtrusive, low-key advertising system possible, people would still react negatively because Wikipedia is known for having no advertising whatsoever.
Contextual alone would completely eliminate their need for panhandling, and would also enable drastic improvements to their infrastructure. Better for users, better for everyone.
>Contextual alone would completely eliminate their need for panhandling, and would also enable drastic improvements to their infrastructure. Better for users, better for everyone.
maybe? but compare wikipedia's uptime to, say, twitter or reddit. Advertising dollars do not always make for reasonable Engineering decisions. (I'm not saying that advertising causes twitter or reddit to go down often; but they both get dramatically more revenue per user. I mean, dramatically more revenue per user, and they both have terrible uptime vs. wikipedia.)
Average cost per user per month in 2012-2013 is roughly $0.007[1]. They also achieved a quite high CTR and donation rate with their banners[2]. Do they really need to trade independency and users trust for (hypothetical) billion-worth ads? One should also keep in mind that non-for-profits must spend all their money in the year.
Perhaps they could, but what could they do with those billions that actually furthers their goals? They're having enough trouble handling the income they already have.
According to Alexa.com, Wikipedia has more traffic than Amazon.com. You said Wikipedia raised $25 million last year. Amazon had over $60 Billion in revenue last year. Obviously Wikipedia is a not-for-profit organization and that's good. Just saying that compared to their user base, they are not making a lot of revenue.
To pile on with business ideas - consider creating a "regex academy" to give out certificates to people who complete your regex course and pass your exam. Your website will draw users, and graduates will flaunt their credentials, drawing more users. This will give people a sense of accomplishment for having invested the time. Also, add some sort of Q&A thing, a-la stack exchange, so regex masters can earn karma by helping others.
Another idea - an interviewing tool. If someone comes to me and says he knows regex, I sit him in front of your website and have him complete a test you will have created for that purpose. Your tool would grade the applicant, so as a hiring manager I won't have to know regex to understand if the applicant knows regex. $20-$50 per test sounds reasonable to me.
Side note about debuggex.com itself: The "Phone Number" example is a bad idea. Please either remove it or otherwise relabel it to warn against using it.
Rationale: Almost everywhere in the world outside of US and Canada, phone numbers do not look like that, and interacting with websites that assume they do is frustrating. Even USians or Canadians may want to enter a phone number with an extension, which would get rejected by that regular expression (a colleague of mine got frustrated to no end by websites and bureaucracy assuming the 3-3-4 style of phone numbers when she moved to Canada, because she prefers not to use a cell phone too much, and her work number has an extension).
Nothing about what has been built or blogged makes me believe this person really understands products or markets.
The logic of the points that are being made is flawed, starting with repeatedly conflating building a product for a small market with solving a small and simple problem. These are not the same.
In general, solving problems for small markets is just as hard as solving problems for big ones.
My advice is, at the level that you understand what to build to get to market, go after the biggest fastest growing markets you can.
I think you misunderstood my argument. That may have been entirely my fault; I'm still learning to write.
Small and simple problems are rare in large markets because everybody is chasing after them. The low-hanging fruit get picked very quickly, and you need to produce more to reach the bleeding edge.
By contrast, smaller markets have more low-hanging fruit simply because there are not as many people picking them.
My apologies if you were offended, I didn't think that I was particularly aggressive.
Certainly not compared to what is possible...
I think I understood your argument, I just disagree with what you are asserting and your conclusion.
There is plenty of low-hanging fruit in big markets, because it is a proportionally bigger tree.
If you add the constraint that you want to do everything on your own, then the markets and problems you can reasonably approach are smaller, but I still argue that from a return on investment perspective, you should be looking for the largest market opportunity that you understand enough to build.
If you care to discuss in person, I'm on twitter with the same name. @ me and we figure out the best way to facilitate a discussion.
>In general, solving problems for small markets is just as hard as solving problems for big ones.
Surely that can't be right.
The very nature of a small market, implies that the solutions are easier - because of less competition, so less innovation is needed, therefore lower return.
With larger markets, not only do you have to solve a problem - you have to solve a problem better/different than your competitors.
Not all solutions are created equally and not all solutions solve the problem in the way the customer wants.
It's harder to separate the signal from the noise when the customer doesn't know what the solution should look like - and when the competitors don't know either.
Quite often, in a large market, many competitors exist largely because no 'significantly better' alternative exists. Think about all the crappy desktop software (from the 90s or early 2000s) that many small businesses still use.
In a smaller market, you are more likely able to get away with simpler solutions - e.g. a CRUD web app, versus having to come up with a more sophisticated solution because competitors have already squeezed as much out of CRUD apps as they can.
Competition and the size of the market are not always correlated.
The superior strategy is to maximize returns against efforts, not minimize potential for competition.
The essential argument is that a small market provides small returns therefore go after small markets is not the same as proving that the returns are better in proportion to the cost, in time, resources or opportunity.
Most large markets are divided in following a Pareto distribution, which is to say the winners dominate. You don't have a pie divided between competitors, you have most of the pie going to 2-3 players. Be a player.
When you see a large number of 'competitors' in a market, as often as not the market fragmentation is on the buyer side.
Again, I don't buy the small market simplicity argument, and I especially don't buy that small markets offer the best returns for effort. There is an abundance of large markets, many of which are underserved.
If you see an opportunity to squeeze a little market with a CRUD app, by all means, don't let me stop you, but I don't believe that is a superior strategy.
I won't argue that a superior strategy is to maximize returns against efforts - not minimize potential for competition.
I wasn't making the argument that small markets offer the best returns for effort. Clearly that can't be true either - just by its definition.
The notion that there are an abundance of large markets, many of which are underserved is quite a simplistic argument.
There must be a reason that they are both a) large, and b) underserved.....probably because the barriers to entry are exceedingly high. Energy markets come to mind. Hard to get larger markets than that, but it is easy to find large subsets of customers that are disgruntled and would gladly switch to a `better service`.
The trick is that every Tom, Dick and Harry can't start an energy company. It is VERY capital intensive, even more labor intensive and heavily regulated.
So, I think if you were to reword that statement to say:
"There is an abundance of large markets, many of which are underserved...and easy to reach/service for a single web developer anywhere in the world". I would surely argue that to be false.
If the constraints must allow for traction to start with 'a single web developer anywhere in the world', then I agree that significantly reduces the markets available.
Energy, computer hardware, medical, pharmaceutical, telcom, these are big markets with big stakes, and these are difficult to enter, even for well funded endeavors.
That being said, the internet is still relatively young and acts as a force multiplier enabling anyone to have far greater reach than they could have even 20 years ago.
Relative market size has remained largely undefined to this point. I think the obvious definition of market is in terms of dollars.
What do you consider a large market? A million dollars? tens of millions? 100s of millions?
We should also define abundance.
In 2011, the US GNP was 15,097,083 million USD. If we just say 1% of that is potentially addressable with a technical solution involving the web, that is still over 100 billion in play just in the US.
I don't know about anyone else, but that seems like abundance.
And that's just in the US.
In 2013, as a web developer anywhere in the world, you have never been in a better position to leverage the global economy.
That feels like an abundance.
Perhaps it just comes down to axiomatic world view. Do you see abundance or scarcity?
Again, I say people should go after the biggest market they feel they have a fighting chance to penetrate. Go big, because you can. Fortune favors the bold.
Resource intensity in itself is unlikely to deter entry. A key factor determining industry concentration is the potential for economic profits (rents). You seem to be referring to electric utilities - while regulation is a more plausible entry barrier, the proximate cause is more likely the dearth of rents.
Small markets don't attract large well funded competitors (because their investors don't let them target them or redirect them to larger markets) allowing you to develop and refine an offering you can then aim at larger adjacent markets/segments. One good book that outlines the trade-offs is "The Origin and Evolution of New Business" by Amar Bhide that did a rigorous analysis of the Inc 500 companies.
If the goal to stay small and unfunded, I still take the position that you should look for the largest market you can realistically provide solutions for.
A single programmer writing CRUD apps isn't going to become a competitive telco. I'm not saying wade into fights you can't win,just that if you have to decide between two projects, a considerably larger market should be key to the decision.
What makes you believe that an MVP will be more salable in a small market? I see no model or evidence to support this thinking.
I also believe you are too focused on 'minimal' at the expense of 'viable' in MVP.
If you have relatively a relatively viable product, where would you rather sell? I'll take a big market every time.
If the point is what you say, then why does the original post repeatedly return to the theme of the simplicity of the solution?
I say the person has no understanding of markets because no point being made in the original post is actually about markets, or products for that matter. There is just a list of assertions and assumptions to justify choices that were already made.
If you want to build products for small markets, by all means, go to it.
I spent the first half of my career in the startups in medical software, an industry where the minimal viable product includes a FDA submission. So, no, I am not focused on the 'minimal' at the expense of 'viable'.
In another response you say you don't think you were particularly aggressive. I think you need to evaluate how you present your arguments because you have, twice now, used unnecessary ad hominems.
You've reversed his entire story. He's saying "I built this simple thing and because it's in a small market with no entrenched gorilla's, I'm getting traction, you can too." It's an anecdote, not data, I agree, it does go towards establishing the point he is trying to make.
I was dismissive and probably impolite. I apologized.
You didn't answer my question, so I'll ask it again, what makes you believe that an MVP will be more salable in a small market?
You say 'regardless of the complexity of the MVP', but that invalidates every point the author was trying to make. Point 1, 2 and 3 in the original article all hinge on the level of effort of the MVP.
Where you worked is not something that changes anything about your position.
I reversed nothing. The author asserts some things that are provably false, then asks 'What are your thoughts? Should your first product be aimed at a small market?'
There is traction because something was built that solves a problem. The size of the market and entrenchment of the incumbents are not the same thing. This person can do everything because the problem and solution are small enough to allow that, not because of the size of the market. Further, attributing causal relationships to the size of the market and the traction is a mistake that leads to sub-optimal strategies.
Sometimes building an excellent product or service in a tiny niche can also result in that tiny niche becoming bigger (by either a little or a lot). The MP3 player market was relatively tiny until the iPod blew it apart, ditto for tablets and the iPad, but I'm sure there are more niche examples.
I tend to target niche markets because the odds of me succeeding are much higher. It's much easier to be the best of a small niche and like the article said everything happens on a smaller scale, so less risk. Most the wealthy people I personally know made their money from owning a small niche.
It's easi(er) to own a niche market, but it's also more likely that anyone decently positioned to compete with you can wipe out your profits with small changes to their product or pricing strategy
Not all niche markets are small in terms of revenue/cost either: there are product niches worth millions (or even billions) whose actual feasible customer set barely makes it into double digits. But when the niche is that small in terms of customers you find that despite the lack of threat from competitors it's actually the customer that owns the niche....
That is true, but something else to focus on: with smaller niches, the learning that takes place is often much higher and faster, and that is invaluable too.
My app is the absolute niche of niche ( https://play.google.com/store/apps/details?id=com.pauldavids... ), but I learned A LOT, especially about the official Android publishing process. I don't care if it doesn't get used by many people, because my target market was literally 1 person: my girlfriend.
In addition, the process of making this app was fun. Learning AND fun; a goal that ALL of us here are striving for, right?
Going after such a small niche is a great idea as long as you know that the market is big enough to provide good ROI in both percentage and nominal terms.
I don't think the worry from a competitor "adding a feature and crushing you" is a very likely threat. As long as you can stick it out for a few years to build a brand name and continue to keep in front of the indefinite stream of people learning regex you should be fine.
I don't think I am in your target market based on your current positioning, however I am in a position where I would be involved in the decision as to whether my company would pay money for something like this.
The company I work for (as an SOA architect) uses regex heavily for many mission critical applications. It costs me 100s of Ks in testing effort when a back-end format experiences major change. We usually don't find a lot of bugs in testing but each missed parsing requirement could mean millions to the bottom line thus justifying the investment in man hours.
If you think support of regex is a tiny market, I am not sure you have considered all of your angles or fully understand your market.
OP. Thanks for making debuggex! It has certainly changed the way I write regexes...I now reach for debuggex _before_ I start writing a new (non-trivial) regex. Fantastic tool.
One think that I would really love is to be able to used named capture groups like in Python.
I read your blog post, and have kept named groups on my mind. Support for more languages is planned. However, I should note that it will be a premium feature.
I mainly use Go and am used to Go Playground http://play.golang.org/ for testing very small snippets and sharing them with others in IRC for education/debugging.
Debuggex is already part of my workflow when I write regular expressions, I was using it just yesterday to test some pre-processing of Markdown.
The value to me is already there, but right now it's something I could also do without... but if the regexp engine on Debuggex is the one that is in use in the language in which I wish to implement the regexp, then that does change everything. The value then becomes very high to me.
Debuggex can get you the first 95% of the way, but that last 5% of working out why something is not quite as you expect is where most of the pain is.
I generally find that the last 5% is implementation specific features and syntax (I have only settled on Go recently and tended to work in several languages at a time for the past 5 years, so most of my regexp pain comes from context switching languages and libraries).
Being able to select the exact implementation is the tipping point for me to reach into my pocket and pay.
This was somewhat intentional. I had a larger plug at the beginning initially. I decided it did not seem genuine enough, and would take away from the content.
You are clearly genuine, but also a little naive business wise.
Please give this a read and let me know where the right place to link is, if not here.
1. You are giving me quality content about your business experiences and decisions.
2. You are giving me this information on a blog supporting a product which, by the way you've crafted the blog post, seems likely to be professional and loved.
3. I'm a person who makes and uses regexps, a HN reader and I want to check out the product. I want to do this easily. The web uses links to do this. You've earned the right to link. It is exactly when you should. It is directly relevant and it is in "your home".
If you are in business, this is why you wrote the blog post. You've got me right where you want me. I'm interested and I have money. Make the path between "he should have my money" and "he has my money" as easy as possible. Link.
Anecdotal confirmation: I probably wouldn't have clicked through (or found it) if the only link was the blog image - despite the first thing I did being to look for the link to the product. (Which is great, and might replace my current 'go-to' for this!)
As a small market pursuer, I had to say that a tiny market is different from tiny effort.
I developed torapp guilloche designer (http://www.torapp.info) for security printing industry, which is definitely a tiny market. But it did not mean less competition, and it is in fact much more complicated than a regular graphic editor like adobe illustrator and coreldraw.
Besides regular editing facilities in AI or coreldraw, I spent tremendous effort to handle all possible math formulas/curves as comupter algebraic system (CAS).
I would recommend people to pursue as big market as possible.
I don't think a visual regex debugger is a tiny market- it's every programmer who doesn't totally understand regex, or who will have regex that he needs help decoding. This is probably close to 99% of programmers.
If his market is "programmers who will pay for a regex debugger", it's probably much smaller than 99% of all programmers (and as a sibling comment pointed out, "programmers" are a much smaller market than many other).
Yes it's a huge share of programmers, I'd say 80-90% for your first example 95%+ for your second. But compare that market to the market for Dropbox, or AirBnB, or Amazon.
If you're market is "programmers" it's already a pretty minute fraction of the general population.
The problem is monetizing a small-market product, esp. an online product. If you go the advertising route, you have to get your page views _way_ up to earn anything; you can't do that with just one little server. If you go the subscription route, pricing is really tricky. If you charge just a little, in my personal experience a) most programmers won't pay anything, so you lose most of your market right there, and b) you'll go broke collecting a pittance from the few who will pay.
It feels like this is the quintessential "feature, not product" startup. The goal of these should be either:
A. to acquire a huge customer base and then pivot into satisfying them with a larger "suite" offering which includes your original service as a feature,
or B. to be acquired by another company with a huge customer base... and then integrate your feature into their suite. :)
I could see, for example, Github buying this (and other things like it) and launching a featureful, language-agnostic online IDE that compiles against Travis-CI.
> "Why isn't my regex doing what I intend it to?" I've found that question to be by far the most frustrating and time-consuming issue with developers I've talked to
While I would totally use this tool, this statement indicates to me that he talked to a specific subset of developers.
I know that's kind of what the article is about, but still, this sentence makes it sound like he has solved the biggest time-sink for software developers.
Admittedly I haven't spent too much time testing your product, but I just wanted to point out a few free tools that have been around for a while (which I use often):
i can not say the same about my product http://onetimepost.com/ ... but it only took me a Saturday morning so ... it wasn't like something huge was lost xD
I once spent an entire month developing a very niche product. I figured about 100 people would be interested in it.
Turned out only 11 were. :)
I earned no money, gained no fame.
Still i am happy i did it.
It was challenging enough be fun. Sometimes challenge is all we need.
I don't think your product has a tiny market. Everybody uses regex and nobody actually understands it.
In a smaller market, everything happens on a smaller scale.
No. Scale has nothing to do with market size. Though you picked to build something (not yet a product) that seems to lack a market (defined as people willing to pay for it).
In a smaller market, you can demonstrate expertise.
Its actually easier to demonstrate expertise on bigger markets, due to its density. A small market can only have so many experts.
In a smaller market, you can iterate faster on non-programming skills.
This is more of an attitude than anything else. Its not a big vs small thing itself.
One question I have to ask is why are you trying to develop a new kind of product on an untested market, when you can improve on an existing product and just focus on selling? You are still picking the most difficult choice. And the one that usually tends to deliver a failure.
Once again for everybody: Don't build new things in new markets. Take old things and improve them.
Very cool! Two suggestions: show the examples more prominently (and my add a regex for email, cause it looks cool), and allow people to link to specific regexes.
Interesting arguments...But apart from IDEs like visual studios, How much do individuals and companies pay for developer tools? Like say a better debugger or a code coverage tool? How about VIM plugins or better editors? I too have some ideas for a better debugger that I have been working on.
Others have mentioned it too, but I was blown away with the speed of the renderer! By the time the return key sprang back up, the visualisation was displaying on my screen. How did you do that?
Thank you!
Yup, it's currently coded by hand. I'll find a more scalable way as more pages need to be added to the site. You can see that e.g. the blog post is just a page with a unique link.
I'm in the same boat - building something I really want to build and use myself, not really caring much about product-market fit or any of that other stuff.
Debuggex is a very well done and useful site. It reminds me of http://www.colorzilla.com/gradient-editor/ in terms of utility and slickness of design. Alex Sirota of that site uses a sponsored area that is not obtrusive.
It would be interesting to do a SaaS play and charge on a monthly basis, with all updates available to all users. And then allow some (very basic AND time-limited) use by free users, only for trial purposes (not freemium).
You've got a really targeted and engaged base of returning users. You could add a text link to a product or service for hackers with an affiliate link, you'd probably get pretty high conversions with this audience.
Why? Because you don't need to make 1 cent off each tomato sold in USA to be successful. Even taking a cut of every water pump of a certain car is more then enough--for most of us.
The JavaScript form of the regex follows: [^<]+|<(!(--([^-]-([^-][^-]-)->?)?|\[CDATA\[([^]]]([^]]+])]+([^]>][^]]]([^]]+])]+)>)?|DOCTYPE([ \n\t\r]+([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])|"[^"]"|'[^']'))([ \n\t\r]+)?(\[(<(!(--[^-]-([^-][^-]-)->|[^-]([^]"'><]+|"[^"]"|'[^']')>)|\?([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])(\?>|[\n\r\t ][^?]\?+([^>?][^?]\?+)>))|%([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F]);|[ \n\t\r]+)]([ \n\t\r]+)?)?>?)?)?|\?(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])(\?>|[\n\r\t ][^?]\?+([^>?][^?]\?+)>)?)?|/(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+)?>?)?|(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+)?=([ \n\t\r]+)?("[^<"]"|'[^<']'))*([ \n\t\r]+)?/?>?)?)